gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_movmem): New.
* config/s390/s390.cc (s390_expand_movmem): New.
* config/s390/s390.md (movmem): New.
(*mvcrl): New.
(mvcrl): New.
---
gcc/config/s390/s390-protos.h | 1 +
gcc/config/s390/s390.cc
Do not perform a libc function call into memcpy in case the size is not
a compile-time constant but bounded and the upper bound is less than or
equal to 256 bytes.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_cpymem): Change
function signature.
* config/s390/s39
Vectorize memset with a constant length of less than or equal to 64
bytes.
Do not perform a libc function call into memset in case the size is not
a compile-time constant but bounded and the upper bound is less than or
equal to 256 bytes.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_
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 alignment, though, still adding a
test case in order to make sure
Any thoughts about this?
Cheers,
Stefan
---
gcc/internal-fn.c| 42 ++
gcc/internal-fn.def | 3 +
gcc/target-insns.def | 3 +
gcc/tree-loop-distribution.c | 257 ++-
4 files changed, 272 insertions(+), 33 deletions(-)
diff --git
On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > This patch adds support for recognizing loops which mimic the behaviour
> > of function rawmemchr, and replace
Ping
On Sun, Feb 14, 2021 at 11:27:40AM +0100, Stefan Schulze Frielinghaus wrote:
> On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> > >
> > > This patch a
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 corresponding vchX. Keep testcases
vchX_{lt,gt} where only a relat
On Tue, Mar 02, 2021 at 08:08:14AM +0100, Andreas Krebbel wrote:
> 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 an
On Tue, Mar 02, 2021 at 01:29:59PM +0100, Richard Biener wrote:
> On Sun, Feb 14, 2021 at 11:27 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielin
ping
On Fri, Jun 25, 2021 at 12:23:32PM +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Jun 16, 2021 at 04:22:35PM +0200, Richard Biener wrote:
> > On Mon, Jun 14, 2021 at 7:26 PM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > On Thu, May 20, 2021 at
Over the last couple of months quite a few warnings about uninitialized
variables were raised while building GCC. A reason why these warnings
show up on S/390 only is due to the aggressive inlining settings here.
Some of these warnings (2c832ffedf0, b776bdca932, 2786c0221b6,
1657178f59b) could be
This patch enables a peephole2 optimization which transforms a load of
constant zero into a temporary register which is then finally used to
compare against a floating-point register of interest into a single load
and test instruction. However, the optimization is only applied if both
registers ar
On Mon, Sep 21, 2020 at 06:51:00PM +0200, Andreas Krebbel wrote:
> On 18.09.20 13:10, Stefan Schulze Frielinghaus wrote:
> > This patch enables a peephole2 optimization which transforms a load of
> > constant zero into a temporary register which is then finally used to
> &
eas opts is the set of options which are
implied by opts_set.
What puzzles me right now is that in cl_target_option_save we save in
ptr only options from opts but not from opts_set whereas in
cl_target_option_restore we override some members of opts_set. Thus it
is unclear to me how a backend should restore opts_set then.
I'm probably missing something. Any hints on how to restore opts_set
and especially target_flags?
Cheers,
Stefan
On Wed, Sep 30, 2020 at 11:32:55AM +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > This patch breaks quite a view test cases (target-attribute/tattr-*) on
> > IBM Z. Having
On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> > I think the problem boils down that on S/390 we distinguish between four
> > states of a flag: explicitely set to yes/no and implicitely
On Fri, Oct 02, 2020 at 10:46:33AM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 03:24:08PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> > > On Wed, Sep 30, 2020 at 01:21:44PM
On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote:
> On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote:
> > Over the last couple of months quite a few warnings about uninitialized
> > variables were raised while building GCC. A reason why these warnings
> >
Ping.
On Wed, Sep 07, 2022 at 04:20:25PM +0200, Stefan Schulze Frielinghaus wrote:
> Whenever a new cselib value is created check whether a smaller value
> exists which is contained in the bigger one. If so add a subreg
> relation to locs of the smaller one.
>
>
Ping.
On Wed, Sep 07, 2022 at 04:20:26PM +0200, Stefan Schulze Frielinghaus wrote:
> For parameter of type integer which do not consume a whole register
> (modulo sign/zero extension) this patch adds entry values up to maximal
> register mode.
>
> gcc/ChangeLog:
>
>
For BImode get_narrowest_mode evaluates to QImode but BImode < QImode.
Thus FOR_EACH_MODE_UNTIL never reaches BImode and iterates until OImode
for which no wider mode exists so we end up with VOIDmode and fail.
Fixed by adding a size guard so we effectively skip BImode.
Bootstrap and regtest are c
On Wed, Oct 05, 2022 at 08:48:13PM -0600, Jeff Law via Gcc-patches wrote:
>
> On 10/4/22 05:28, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > For BImode get_narrowest_mode evaluates to QImode but BImode < QImode.
> > Thus FOR_EACH_MODE_UNTIL never reaches BImode and
For a peephole2 condition variable insn points to the first matched
insn. In order to refer to the second matched insn use
peep2_next_insn(1) instead.
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
gcc/ChangeLog:
* config/s390/s390.md (define_peephole2): Variab
For a peephole2 condition variable insn points to the first matched
insn. In order to refer to the second matched insn use
peep2_next_insn(1) instead.
Update: Added a test case
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
gcc/ChangeLog:
* config/s390/s390.md
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 bootstrap and regtest are ok for mainline and gcc-{10,11,12},
ok to instal
For my current use case only some FOR_EACH_MODE macros were missing.
Though I thought I will give it a try and grep'ed through the source
code and added further ones. I didn't manually check all of them but so
far it looks good to me.
Ok for mainline?
contrib/ChangeLog:
* clang-format:
On Wed, Aug 17, 2022 at 01:50:45PM +0200, 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 indenta
For variable tracking there exists cases where a value is moved in a
wider mode than its native mode. For example:
int
foo (int x)
{
bar (x);
return x;
}
compiles on IBM zSystems into
0x010012b0 <+0>: stmg%r12,%r15,96(%r15)
0x010012b6 <+6>: lgr %r12,%r2
0x000
Whenever a new cselib value is created check whether a smaller value
exists which is contained in the bigger one. If so add a subreg
relation to locs of the smaller one.
gcc/ChangeLog:
* cselib.cc (new_cselib_val): Keep track of further subvalue
relations.
---
gcc/cselib.cc | 20
For parameter of type integer which do not consume a whole register
(modulo sign/zero extension) this patch adds entry values up to maximal
register mode.
gcc/ChangeLog:
* var-tracking.cc (vt_add_function_parameter): Add entry values
up to maximal register mode.
---
gcc/var-track
ntrib/test_summary scripts, thus no LAST_UPDATED
> included?)
Indeed the reports don't include a git commit id. We are using both
scripts. However, since the git repository is setup differently in our
case, we had been using `gcc_update --touch` only. Thus the files
LAST_UPDATED as well as gcc/REVISION were not created. I changed that
such that both are created, now. Thanks for letting me know!
Cheers,
Stefan
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 insertions(+)
diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
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 deletion(-)
diff --git a/gcc/config/s390/vx-builtins.md b/gcc/config/s
On Thu, Nov 12, 2020 at 02:18:13PM +0100, Andreas Krebbel wrote:
> 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")
As pointed out in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558816.html
this instruction pattern will be removed anyway. Thus we can ignore
this patch.
On Thu, Nov 12, 2020 at 01:25:35PM +0100, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for mas
EM_REF out of SSA_NAME/ADDR_EXPR in expand_RAWMEMCHR? Not sure if
MEM_REF is supposed to be the canonical form here.
>
> +}
> +
> +static bool
> +reduction_var_overflows_first (tree reduction_var, tree load_type)
> +{
> + unsigned precision_ptrdiff =
On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
> > [...]
> > > > >
> > > > &g
:00 2001
From: Stefan Schulze Frielinghaus
Date: Mon, 8 Feb 2021 10:35:39 +0100
Subject: [PATCH 2/2] IBM Z: Provide rawmemchr{qi,hi,si} expander
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_rawmemchrqi): Add prototype.
(s390_rawmemchrhi): Add prototype.
(s390_rawmemch
ping
On Mon, Oct 11, 2021 at 02:14:53PM +0200, Stefan Schulze Frielinghaus wrote:
> On Mon, Oct 11, 2021 at 09:38:36AM +0200, Richard Biener wrote:
> > On Fri, Oct 8, 2021 at 1:31 PM Stefan Schulze Frielinghaus via
> > Gcc-patches 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 | "TARGET_HTM && operands != NULL
build/gencondmd.c:59:12: note: 'opera
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:
* gcc.dg/tree-ssa/ldist-rawmemchr-1.c: For IBM Z set arch to z13
and use z/Architecture s
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.
---
gcc/config/s390/s390.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c b/gcc/co
On Tue, Nov 02, 2021 at 04:20:01PM +0100, Andreas Schwab wrote:
> On Nov 02 2021, Stefan Schulze Frielinghaus via Gcc-patches wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > b/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > index
On Thu, May 20, 2021 at 11:24:57AM +0200, Richard Biener wrote:
> On Fri, May 7, 2021 at 2:32 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Wed, May 05, 2021 at 11:36:41AM +0200, Richard Biener wrote:
> > > On Tue, Mar 16, 2021 at 6:13 PM Stefan Schulz
gcc/ChangeLog:
* regcprop.c (maybe_mode_change): Determine offset relative to
high or low part depending on endianness.
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
---
gcc/regcprop.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
d
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/pipermail/gcc-patches/2021-September/579649.html
> >
> > Bo
On Mon, Oct 11, 2021 at 09:38:36AM +0200, Richard Biener wrote:
> On Fri, Oct 8, 2021 at 1:31 PM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > gcc/ChangeLog:
> >
> > * regcprop.c (maybe_mode_change): Determine offset relative to
> >
On Fri, Sep 17, 2021 at 10:08:27AM +0200, Richard Biener wrote:
> On Mon, Sep 13, 2021 at 4:53 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> > > On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulz
While determining the precission of reduction_var an SSA_NAME instead of
its TREE_TYPE is used. Streamlined with other TREE_TYPE (reduction_var)
uses.
Bootstrapped and regtested on x86 and IBM Z. Committed as per PR102752.
gcc/ChangeLog:
* tree-loop-distribution.c (reduction_var_overfl
ping
On Thu, Apr 08, 2021 at 10:23:31AM +0200, Stefan Schulze Frielinghaus wrote:
> ping
>
> On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> > [snip]
> >
> > Please find attached a new version of the patch. A major change compared t
For move2add_valid_value_p we also have to ask the target whether a
register can be accessed in a different mode than it was set before.
gcc/ChangeLog:
PR rtl-optimization/100263
* postreload.c (move2add_valid_value_p): Ensure register can
change mode.
Bootstrapped and re
On Wed, May 05, 2021 at 11:36:41AM +0200, Richard Biener wrote:
> On Tue, Mar 16, 2021 at 6:13 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > [snip]
> >
> > Please find attached a new version of the patch. A major change compared to
> > the previous patch is
The type of the output operands *p and *q of the extended asm statement
of function foo is unsigned long whereas the type of the corresponding
input operands is int. This results, e.g. on IBM Z, in the case that
the immediates 2 and 3 are written into registers in SI mode and read in
DI mode resul
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
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for
Ping.
On Thu, Aug 24, 2023 at 11:31:32AM +0800, Xi Ruoyao wrote:
> Ping again.
>
> On Fri, 2023-08-18 at 13:04 +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > Ping. Since this fixes bootstrap problem PR110939 for Loongarch I'm
> > pingen this one
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?
In function s390_const_operand_ok the immediate is checked whether it is
valide w.r
e rotate. Maybe I'm wrong?
Cheers,
Stefan
diff --git a/gcc/match.pd b/gcc/match.pd
index 9cb37740f1e..0297f8c9c89 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2986,6 +2986,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ tree rotate_type = TREE_TYPE (@0); }
(convert (rotate (convert:rot
On Mon, Mar 23, 2020 at 04:44:56PM +0100, Richard Biener wrote:
> On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek wrote:
> >
> > On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > > I wonder if we can leverage the bswap pass for rotate detection
> > > (see find_bswap_or_nop which ma
gcc/ChangeLog:
* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them. For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define
Bootstrapped and regtested on s390x with and without a patched gas. Ok
for master?
gcc/ChangeLog:
* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them. For other targets the logic
stays the s
Bootstrapped and regtested on s390x with and without patched gas. Ok for
releases/gcc-10 branch?
On Thu, Jul 09, 2020 at 09:29:21AM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * config/s390/s390.c (print_op
On Thu, Jul 09, 2020 at 09:35:42AM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> Bootstrapped and regtested on s390x with and without a patched gas. Ok
> for master?
Ok for releases/gcc-9 branch? (not for master of course, sorry for the
confusion).
> gcc/
Backport for supporting vector load/store alignment hints for GCC8.
Bootstrapped and regtested on s390x with and without patched gas. Ok for
releases/gcc-8 branch?
Andreas Krebbel (1):
S/390: Support vector load/store alignment hints
Stefan Schulze Frielinghaus (1):
S/390: Emit vector
gcc/ChangeLog:
* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them. For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define
From: Andreas Krebbel
The IBM z14 POP adds an optional alignment operand to the vl, vst,
vlm, and vstm instruction (vector loads and stores). Vectors residing
on 8 or 16 byte boundaries might get loaded or stored faster on some
models given the instruction uses the proper hint operand. A wrong
h
This is a follow up to commit 5c9669a0e6c respectively discussion
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html
In case that an alignment constraint is less than the size of a
corresponding scalar type, ensure that we advance at least by one
iteration. For example, on s390x we h
>> Richard Biener via Gcc-patches writes:
> > >> > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via
> > >> > Gcc-patches wrote:
> > >> >>
> > >> >> This is a follow up to commit 5c9669a0e6c respectively disc
On Tue, Jul 28, 2020 at 08:55:57AM +0200, Richard Biener wrote:
> On Mon, Jul 27, 2020 at 4:20 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Mon, Jul 27, 2020 at 12:29:11PM +0200, Richard Biener wrote:
> > > On Mon, Jul 27, 2020 at 11:45 AM Ric
On Wed, Jul 29, 2020 at 09:11:12AM +0200, Richard Biener wrote:
> On Tue, Jul 28, 2020 at 5:36 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Tue, Jul 28, 2020 at 08:55:57AM +0200, Richard Biener wrote:
> > > On Mon, Jul 27, 2020 at 4:20 PM Stefan Schulz
ChangeLog:
2020-04-22 Stefan Schulze Frielinghaus
* MAINTAINERS (Write After Approval): add myself
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f37e9e68622..336346a37a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -582,6 +582,7
Hi,
The attached patch fixes several test cases. Successfully bootstrapped and
regtested on S/390. Ok for master?
Cheers,
Stefan
gcc/ChangeLog:
2020-04-21 Stefan Schulze Frielinghaus
* config/s390/s390.md ("*_ior_and_sr_ze"): lift from SI
m
Hi,
Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
Ok for master?
Cheers,
Stefan
gcc/ChangeLog:
2020-04-21 Stefan Schulze Frielinghaus
* config/s390/s390.md ("*_ior_and_sr_ze"): lift from SI
mode to DSI ("*trunc_sidi_and_s
On Wed, Apr 22, 2020 at 02:14:11PM +0200, Andreas Krebbel wrote:
> On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote:
> > Hi,
> >
> > Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
> > Ok for master?
> >
> > Cheers,
> > Stefa
On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> > some function calls trigger the stack-protector-strong although such
> > calls are later on implemented via calls to internal function
Array retval is not necessarily initialized by function is_call_safe and
may be used afterwards. Thus, initialize it explicitly.
Ok for master?
gcc/ChangeLog:
2020-04-27 Stefan Schulze Frielinghaus
PR tree-optimization/94774
* gimple-ssa-sprintf.c
ssfully on S/390. Ok for master?
gcc/ChangeLog:
2020-04-28 Stefan Schulze Frielinghaus
* toplev.c (output_stack_usage_1): Ensure that first
argument to fprintf is not null.
---
gcc/toplev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/toplev.c
-attribs.c:3695:26: note: 'nunits' was declared here
3695 | unsigned HOST_WIDE_INT nunits;
|
This is fixed by also checking whether ARGS is null or not.
Bootstrapped and regtested on S/390. Ok for master?
gcc/c-family/ChangeLog:
2020-04-28 Stefan Schulze Fri
hint is not totally perfect).
By initialising pre we silence the warning.
Bootstrapped and regtested on S/390. Ok for master?
gcc/ChangeLog:
2020-04-28 Stefan Schulze Frielinghaus
* var-tracking.c (vt_initialize): Initialize local variable pre.
---
gcc/var-tracking.c | 2 +-
1 file changed, 1 i
zero mimics the behavior of an uninitialized
variable except UB because zero is the only value it is tested for at the
moment. Since num is used as an index into array asynchronous initializing it
to 2 seems plausible.
Bootstrapped and regtested on S/390. Ok for master?
gcc/fortran/Change
On Tue, Apr 28, 2020 at 11:33:31AM +0200, Richard Biener wrote:
> On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > In function handle_vector_size_attribute local variable nunits is
> > supposed to be initialized by function ty
On Tue, Apr 28, 2020 at 11:44:58AM +0200, Richard Biener wrote:
> On Tue, Apr 28, 2020 at 11:28 AM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > While bootstrapping GCC on S/390 the following warning/error is raised:
> >
> > gcc/var-tracking.c:1023
Hi Tobias,
On Tue, Apr 28, 2020 at 05:06:15PM +0200, Tobias Burnus wrote:
> Hi Stefan,
>
> I prefer Jakub's suggestion – his change LGTM.
Please find attached an updated patch. Bootstrapped and regtested on
S/390. Ok for master?
Cheers,
Stefan
> On 4/28/20 2:30 PM, Jaku
On Tue, Apr 28, 2020 at 08:27:12PM +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, Apr 28, 2020 at 11:33:31AM +0200, Richard Biener wrote:
> > On Tue, Apr 28, 2020 at 10:03 AM Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> > >
> > > In function h
On Mon, May 04, 2020 at 03:19:02PM +0200, Richard Biener wrote:
> On Mon, May 4, 2020 at 1:44 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Tue, Apr 28, 2020 at 08:27:12PM +0200, Stefan Schulze Frielinghaus wrote:
> > > On Tue, Apr 28, 2020 at 11:33:31AM
On Tue, May 05, 2020 at 02:58:51PM +0200, Richard Biener wrote:
> On Mon, May 4, 2020 at 4:07 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Mon, May 04, 2020 at 03:19:02PM +0200, Richard Biener wrote:
> > > On Mon, May 4, 2020 at 1:44 PM Stefan Schulz
initialising the mentioned variables.
Bootstrapped on S/390. Ok for master and releases/gcc-10 assuming that
regtest succeeds (still running but I don't see a reason why it
should fail)?
gcc/ChangeLog:
2020-05-05 Stefan Schulze Frielinghaus
PR tree-optimization/94952
* g
ootstrapped and regtested on S/390. Ok for master?
gcc/fortran/ChangeLog:
2020-05-04 Stefan Schulze Frielinghaus
* matchexp.c (match_add_operand): Initialize local variable e.
---
gcc/fortran/matchexp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/fo
Vector alignment hints are fully supported since z14. On z13 alignment
hints have no effect, however, instructions with alignment hints are
still legal. Thus, emit alignment hints also for z13 targets so that if
the binary is actually run on a z14 or later it benefits from such
hints.
Note, this
Forgot to mention:
Bootstrapped and regtested on z13 and z14 with gas including f687f5f563
Ok for master?
On Thu, May 28, 2020 at 08:24:26PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> Vector alignment hints are fully supported since z14. On z13 alignment
> hints h
On Fri, May 29, 2020 at 01:57:30PM +0200, Andreas Krebbel wrote:
> On 28.05.20 20:24, Stefan Schulze Frielinghaus wrote:
> > Vector alignment hints are fully supported since z14. On z13 alignment
> > hints have no effect, however, instructions with alignment hints are
> > sti
Ping
On Tue, May 19, 2020 at 08:33:24AM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> While bootstrapping GCC on S/390 the following warning is raised:
>
> gcc/fortran/matchexp.c: In function 'match match_level_5(gfc_expr**)':
> gcc/fortran/matchexp.c:401
Since 87cb9423add vector alignment hints are emitted for target z13,
too. This patch changes this behaviour in the sense that alignment
hints are only emitted for target z13 if the assembler accepts them.
Bootstrapped and regtested on S/390. Ok for master?
gcc/ChangeLog:
* config.in: Re
In case the vectorized version of strlen is used, then each memory
access inside the loop is 16-byte aligned. Thus add this kind of
information so that vector alignment hints can later on be emitted.
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/s390.
On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote:
> > On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote:
> > > Over the last couple of months quite a few warnings a
On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote:
>
> On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> >> On Tue, Sep 22, 2020 a
On Wed, Oct 28, 2020 at 11:34:53AM -0600, Jeff Law wrote:
>
> On 10/28/20 11:29 AM, Stefan Schulze Frielinghaus wrote:
> > On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote:
> >> On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> >>&
On Mon, Jan 23, 2023 at 02:21:46PM +0100, Iain Buclaw wrote:
> Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar
> 13, 2023 6:54 pm:
> > In the context of D the interpretation of S390, S390X, and SystemZ is a
> > bit fuzzy. The wording S390X wa
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
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for
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 reset and subsequently wrong state is propagated
to following
301 - 400 of 414 matches
Mail list logo
