On Tue, 2022-09-27 at 02:23 +0200, Ilya Leoshkevich wrote:
> Hi,
>
> This is a resend of v4 with slightly adjusted commit messages:
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
> v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
> v3:
Currently s390 emits the following sequence to store a frame_pc:
a:
.LASANPC0:
lg %r1,.L5-.L4(%r13)
la %r1,0(%r1,%r12)
stg %r1,176(%r11)
.L5:
.quad .LASANPC0@GOTOFF
The reason GOT
gcc/ChangeLog:
2020-06-30 Ilya Leoshkevich
* asan.cc (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY.
* defaults.h (CODE_LABEL_BOUNDARY): New macro.
* doc/tm.texi: Document CODE_LABEL_BOUNDARY.
* doc/tm.texi.in: Likewise.
---
gcc/asan.cc| 1 +
Hi,
This is a resend of v4 with slightly adjusted commit messages:
v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html
v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html
v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
v4:
On Thu, 2022-08-11 at 07:45 +0200, Andreas Krebbel wrote:
> 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
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 recognize, but can't,
> because it's not defined
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 defining it for all vector
modes supported by
On Fri, 2022-04-29 at 13:56 +0200, Jakub Jelinek wrote:
> On Fri, Apr 29, 2022 at 01:52:49PM +0200, Ilya Leoshkevich wrote:
> > > This doesn't resolve the problem, unfortunately, because
> > > references to discarded comdat symbols are still kept in .rodata:
> > >
> > >
On Thu, 2022-04-28 at 14:05 +0200, Ilya Leoshkevich wrote:
> On Thu, 2022-04-28 at 13:27 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> > > This is determined by default_elf_select_rtx_section (). If we
> > > don't
> > > want to mix non-reloc
On Thu, 2022-04-28 at 13:27 +0200, Jakub Jelinek wrote:
> On Thu, Apr 28, 2022 at 01:03:26PM +0200, Ilya Leoshkevich wrote:
> > This is determined by default_elf_select_rtx_section (). If we
> > don't
> > want to mix non-reloc and reloc constants, we need to define a
> > special
> > section
On Wed, 2022-04-27 at 14:46 +0200, Jakub Jelinek wrote:
> On Wed, Apr 27, 2022 at 02:23:00PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 27, 2022 at 11:59:49AM +0200, Ilya Leoshkevich wrote:
> > > I get a .LASANPC reloc there in the first place because of
> > >
On Wed, 2022-04-27 at 11:59 +0200, Ilya Leoshkevich via Gcc-patches
wrote:
> On Wed, 2022-04-27 at 11:33 +0200, Jakub Jelinek wrote:
> > On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-
> > patches wrote:
> > > Bootstrapped and regtested on x86_64-redh
On Wed, 2022-04-27 at 11:33 +0200, Jakub Jelinek wrote:
> On Wed, Apr 27, 2022 at 11:27:49AM +0200, Ilya Leoshkevich via Gcc-
> patches wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux and
> > s390x-redhat-linux. Ok for master (or GCC 13 in case this doesn't
Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux. Ok for master (or GCC 13 in case this doesn't fit
stage4 criteria)?
Building C++ template-heavy code with ASan sometimes leads to bogus
"defined in discarded section" linker errors.
The reason is that .rodata.FUNC.cstN
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 (current_function_section ()).
First of all, this is
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 (current_function_section ()).
First of all, this is unnecessary - the
This helps with generating code for kernel hotpatches, which contain
individual functions and are loaded more than 2G away from vmlinux.
This should not create performance regressions for the normal use
cases, because for local functions ld replaces @PLT calls with direct
calls.
gcc/ChangeLog:
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 tools (e.g. kpatch), so don't generate them.
gcc/ChangeLog:
* config/s390/s390.c (s390_function_profiler): Ignore labelno
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 regtested on s390x-redhat-linux.
Ok for gcc-11?
Best regards,
On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote:
> On Sun, 26 Sep 2021, Ilya Leoshkevich wrote:
>
> > Add both positive and negative tests.
>
> The tests will likely be quite fragile with respect to what is
> actually vectorized on which target. If you move the tests
> to gcc.dg/vect/
Add both positive and negative tests.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/reassoc-46.c: New test.
* gcc.dg/tree-ssa/reassoc-46.h: Common code for new tests.
* gcc.dg/tree-ssa/reassoc-47.c: New test.
* gcc.dg/tree-ssa/reassoc-48.c: New test.
*
PR tree-optimization/49749 introduced code that shortens dependency
chains containing loop accumulators by placing them last on operand
lists of associative operations.
456.hmmer benchmark on s390 could benefit from this, however, the code
that needs it modifies loop accumulator before using it,
Biasing loop-carried PHIs during the 1st reassociation pass interferes
with reduction chains and does not bring measurable benefits, so do it
only during the 2nd reassociation pass.
gcc/ChangeLog:
* passes.def (pass_reassoc): Rename parameter to early_p.
*
v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579976.html
Changes in v3:
* Do not propagate bias along tcc_references.
* Call get_rank () before checking biased_names.
* Add loop-carried phis to biased_names.
* Move the propagate_bias_p () call outside of the loop.
* Test with
On Thu, 2021-09-23 at 13:55 +0200, Richard Biener wrote:
> On Wed, 22 Sep 2021, Ilya Leoshkevich wrote:
>
> > PR tree-optimization/49749 introduced code that shortens dependency
> > chains containing loop accumulators by placing them last on operand
> > lists of associative operations.
> >
> >
Add both positive and negative tests.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/reassoc-46.c: New test.
* gcc.dg/tree-ssa/reassoc-46.h: Common code for new tests.
* gcc.dg/tree-ssa/reassoc-47.c: New test.
* gcc.dg/tree-ssa/reassoc-48.c: New test.
*
PR tree-optimization/49749 introduced code that shortens dependency
chains containing loop accumulators by placing them last on operand
lists of associative operations.
456.hmmer benchmark on s390 could benefit from this, however, the code
that needs it modifies loop accumulator before using it,
Biasing loop-carried PHIs during the 1st reassociation pass interferes
with reduction chains and does not bring measurable benefits, so do it
only during the 2nd reassociation pass.
gcc/ChangeLog:
* passes.def (pass_reassoc): Rename parameter to early_p.
*
This is an update to my very old patch with the review comments
addressed. Bootstrapped and regtested x86_64-redhat-linux,
ppc64le-redhat-linux and s390x-redhat-linux.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548785.html
Changes in v2:
* Disable PHI biasing in the early pass
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
libsanitizer/ChangeLog:
* configure.tgt (s390*-*-linux*): Enable LSan and TSan for
s390x.
---
libsanitizer/configure.tgt | 5 +
1 file changed, 5 insertions(+)
diff --git a/libsanitizer/configure.tgt
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.
* gcc.target/s390/load-imm64-1.c: Use unsigned long long.
*
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 not append @PLT only to
weak symbols in
On Wed, 2021-07-07 at 21:03 +0200, 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
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 not append @PLT only to
weak symbols in
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
This helps with generating the code for kernel hotpatches, which
contain individual functions and are loaded more than 2G away from
vmlinux. This should not create performance regressions for the
normal use cases, because for
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 nops that we generate for
-mnop-mcount is not
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 tools (e.g. kpatch), so don't generate them.
gcc/ChangeLog:
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 *ashrdi3_31 is not only no
longer necessary, but actually breaks
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 now fixed). Ok for master?
> >
> > v1:
> >
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 efficient, but is more
on the "obviously correct"
Bootstrapped and regtested on s390x-redhat-linux. Tested with valgrind
on top of 52a5515ed (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100278). Ok for master?
gen_fprx2_to_tf() and gen_tf_to_fprx2() cannot handle hard registers,
since the subregs they create do not pass validation.
On Tue, 2021-03-23 at 12:48 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > +inline use_info *
> > +set_info::single_nondebug_use () const
> > +{
> > + use_info *nondebug_insn = single_nondebug_insn_use ();
> > + if (nondebug_insn)
> > + return has_phi_uses () ? nullptr :
Bootstrap and regtest running on x86_64-redhat-linux,
ppc64le-redhat-linux and s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566127.html
v1 -> v2: Pass a set_info instead of a def_info around.
Add single_nondebug_insn_use () - maybe this
On Mon, 2021-03-22 at 22:55 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > On Mon, 2021-03-22 at 18:23 +, Richard Sandiford wrote:
> > > Ilya Leoshkevich writes:
> >
> > [...]
> >
> > > > Do you still want me to add single_nondebug_use() for
> > > > completeness
> > > > in
Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566127.html
v1 -> v2: Pass a set_info instead of a def_info around.
Add single_nondebug_insn_use () - maybe this could
On Mon, 2021-03-22 at 18:23 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
[...]
> > Do you still want me to add single_nondebug_use() for completeness
> > in
> > this patch, or would it be better to add it later when it's
> > actually
> > needed?
>
> I was thinking that the
On Sun, 2021-03-21 at 13:19 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-
> > linux
> > and s390x-redhat-linux. Ok for master?
>
> Given what was said downthread, I agree we should fix this for GCC
> 11.
> Sorry
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 (VEC_REGS), but the code generated
by s390_md_asm_adjust()
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: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
v2 -> v3:
- The main prereq is now committed:
On Wed, 2021-03-03 at 21:26 +0100, Ilya Leoshkevich via Gcc-patches
wrote:
> On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote:
> >
> >
> > On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > > Hello,
> > >
> > > I would like to ping t
On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote:
>
>
> On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > Hello,
> >
> > I would like to ping the following patch:
> >
> > Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
> > h
On Wed, 2021-03-03 at 11:34 -0700, Jeff Law wrote:
>
>
> On 3/2/21 3:37 PM, Ilya Leoshkevich via Gcc-patches wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-
> > linux
> > and s390x-redhat-linux. Ok for master?
> >
> >
>
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. Fix by requiring s390_z14_hw
> > target.
> >
> > gcc/testsuite/ChangeLog:
> >
> >
Hello,
I would like to ping the following patch:
Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html
It is needed for the following regression fix:
IBM Z: Fix usage of "f" constraint with long doubles
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+.
* gcc.target/s390/mul-signed-overflow-2.c: Likewise.
Bootstrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
Commit efb6bc55a93a ("fwprop: Allow (subreg (mem)) simplifications")
introduced a check that was supposed to look at the propagated def's
number of uses. It uses insn_info::num_uses
When switching the s390 backend to store long doubles in vector
registers, the patterns for long double <-> DFP conversions were
forgotten. This did not cause observable problems so far, because
libdfp calls are emitted instead of pfpo. However, when building
libdfp itself, this leads to
gcc/ChangeLog:
* config/s390/vector.md (*fprx2_to_tf): Rename to fprx2_to_tf,
add memory alternative.
(tf_to_fprx2): New pattern.
---
gcc/config/s390/vector.md | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git
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
Ilya Leoshkevich (2):
IBM Z: Improve FPRX2 <-> TF
Hello,
I would like to ping the following patch:
Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html
It is needed for the following regression fix:
IBM Z: Fix usage of "f" constraint with long doubles
Hello,
I would like to ping the following patch:
lra: clear lra_insn_recog_data after simplifying a mem subreg
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563428.html
Best regards,
Ilya
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 %.
After switching the s390 backend to store long doubles in vector
registers, "f" constraint broke when used with the former:
On Wed, 2021-01-27 at 08:58 +0100, Andreas Krebbel wrote:
> 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 &
On Thu, 2021-01-21 at 12:29 +, Richard Sandiford wrote:
> Given what you said in the other message about combine, I agree this
> is a reasonable workaround. I don't know whether it's suitable for
> stage 4 or whether it would need to wait for stage 1.
Thanks for reviewing! I've implemented
On Thu, 2021-01-21 at 10:49 +, Richard Sandiford wrote:
> Ilya Leoshkevich via Gcc-patches writes:
> > On Tue, 2021-01-19 at 09:41 +0100, Richard Biener wrote:
> > > On Mon, Jan 18, 2021 at 11:04 PM Ilya Leoshkevich via Gcc-patches
> > > wrote:
> > > Su
Hello,
I would like to ping the following patch:
Add input_modes parameter to TARGET_MD_ASM_ADJUST hook
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html
It is needed for the following regression fix:
IBM Z: Fix usage of "f" constraint with long doubles
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563800.html
v1 -> v2: Allow (mem) -> (subreg) propagation only for single uses.
Boostrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
Suppose we have:
(set (reg/v:TF 63)
On Tue, 2021-01-19 at 09:41 +0100, Richard Biener wrote:
> On Mon, Jan 18, 2021 at 11:04 PM Ilya Leoshkevich via Gcc-patches
> wrote:
> >
> Suppose we have:
> >
> > (set (reg/v:TF 63) (mem/c:TF (reg/v:DI 62)))
> > (set (reg:FPRX2
Boostrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. I realize it might be too late for a change
like this, but it's desirable to have this in conjunction with the
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html s390
regression fix,
Bootstrapped and regtested on s390x-redhat-linux. Depends on
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562898.html;
ok for master once the dependency is committed?
After switching the s390 backend to store long doubles in vector
registers, "f" constraint broke when used with the
Hello,
I ran into this problem when writing new patterns for s390. I'm not
100% sure this fix is correct, but it resolves my issue and survives
bootstrap and regtest on x86_64-redhat-linux, ppc64le-redhat-linux and
s390x-redhat-linux. Could you please take a look?
Best regards,
Ilya
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
* config/s390/vector.md (*tf_to_fprx2_0): Rename from
*mov_tf_to_fprx2_0
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 vector registers, so that
they could fine-tune their asm
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
Give end users the opportunity to find out whether long doubles are
stored in floating-point register pairs or in vector registers, so that
they could fine-tune their asm statements.
gcc/ChangeLog:
2020-12-14 Ilya Leoshkevich
Bootstrapped and regtested on x86_64-redhat-linux. I also built
cross-compilers for arm-linux-gnueabi, cris-elf mn10300-elf,
nds32-linux-gnu, pdp11-aout (didn't fully work due to
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg251887.html,
but the changed code compiled fine),
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 always returns false.
gcc/testsuite/ChangeLog:
2020-12-10
On Fri, 2020-12-11 at 07:51 -0500, Nathan Sidwell wrote:
>
> I'm pretty sure this is wrong. I think the test_text in
> inclhack.def
> should be a pre-fixed string that the testsuite presumably checks is
> converted.
You're right; I've added your change from the Bugzilla and updated the
Tested on gcc121 (x86_64 CentOS Linux 7). Ok for master?
After 92648faa1cb2 ("aix: Fixinclude") make check-fixincludes began to
fail (at least on gcc121 machine). Fix by updating fixincludes/tests
and rerunning genfixes.
fixincludes/ChangeLog:
2020-12-11 Ilya Leoshkevich
*
Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
Commit 2ead1ab91123 ("Limit perf data buffer during profiling") added
-m8 to perf invocations during running tests, but the same problem
exists for checking whether perf is working in the first place.
gcc/testsuite/ChangeLog:
On Thu, 2020-07-09 at 14:07 +0200, Ilya Leoshkevich wrote:
> On Wed, 2020-07-01 at 21:48 +0200, Ilya Leoshkevich wrote:
> > On Wed, 2020-07-01 at 11:57 -0600, Jeff Law wrote:
> > > On Wed, 2020-07-01 at 14:29 +0200, Ilya Leoshkevich via Gcc-
> > > patches
> &g
On Wed, 2020-12-02 at 11:42 -0700, Jeff Law wrote:
>
> On 12/1/20 7:09 PM, Ilya Leoshkevich wrote:
> > On Tue, 2020-12-01 at 15:34 -0700, Jeff Law wrote:
> > > No strong opinions. I think whichever is less invasive in terms
> > > of
> > > code
> > > quality is probably the way to go. What we
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 comparison tests, where (a <= b && a >= b) is turned into
(a <=
Bootstrap ang regtest running on x86_64-redhat-linux. Ok for master?
gcc/ChangeLog:
2020-12-03 Ilya Leoshkevich
* tree-ssa-strlen.c (printf_strlen_execute): Avoid division by
0.
---
gcc/tree-ssa-strlen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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 loads large immediates into GPRs from the literal pool,
which is not
On Wed, 2020-12-02 at 08:15 +0100, Andreas Krebbel wrote:
> 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?
>
On Tue, 2020-12-01 at 15:34 -0700, Jeff Law wrote:
>
> No strong opinions. I think whichever is less invasive in terms of
> code
> quality is probably the way to go. What we want to avoid is
> suppressing
> threading unnecessarily as that often leads to false positives from
> middle-end based
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 literal pool,
which is not as efficient as loading two halves
Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux. Ok for master?
This is the same as dcd2ca63ec5c ("Introduce can_vcond_compare_p
function"), but for vec_cmp. The reason it's needed is that since
5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in vec_cmp")
and
Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux. Ok for master?
During ICE reporting, sometimes rtl_dump_bb is called on partially
initialized basic blocks. This produces another ICE, obscuring the
original problem.
Fix by checking that that basic blocks are
Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux. Ok for master?
When diffing test results, there sometimes occur spurious "New tests
that PASS" / "Old tests that passed, that have disappeared" messages.
The reason is that if create_gcov is not installed, then the
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 supported by the hardware. Restrict
this by using
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:
2020-11-23 Ilya Leoshkevich
*
On Fri, 2020-11-20 at 12:14 -0700, Jeff Law wrote:
>
> On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
> > v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> >
> > This is the implementation of Jakub's suggestion: allow
> > __builtin_constant_p () after IPA, but fold it into 0.
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.
* gcc.target/s390/vector/long-double-caller-abi-run.c: Use the
Bootstrap and regtest running on s390x-redhat-linux with --enable-shared
--with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking=yes,rtl --enable-gnu-indirect-function
--disable-werror --enable-languages=c,c++,fortran,objc,obj-c++
--with-arch=arch13. Ok for master?
gcc/testsuite/ChangeLog:
2020-11-05 Ilya Leoshkevich
* gcc.target/s390/vector/long-double-callee-abi-scan.c: New test.
* gcc.target/s390/vector/long-double-caller-abi-run.c: New test.
* gcc.target/s390/vector/long-double-caller-abi-scan.c: New test.
*
On z14+, there are instructions for working with 128-bit floats (long
doubles) in vector registers. It's beneficial to use them instead of
instructions that operate on floating point register pairs, because it
allows to store 4 times more data in registers at a time, relieving
register pressure.
Bootstrapped and regtested on s390x-redhat-linux with --with-arch=z15.
Ok for master?
This patch series implements storing long doubles in vector registers
on z14+. Patch 1 is the actual implementation, patch 2 adds tests.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557968.html
On Wed, 2020-11-04 at 18:28 +0100, Andreas Krebbel wrote:
> These tests all use the -mzvector option but do not appear to make
> use of the z vector languages
> extensions. I think that option could be removed. Then these tests
> should be moved to the vector subdir.
Will change, thanks!
> You
On Wed, 2020-11-04 at 18:16 +0100, Andreas Krebbel wrote:
> On 03.11.20 22:45, Ilya Leoshkevich wrote:
> > On z14+, there are instructions for working with 128-bit floats
> > (long
> > doubles) in vector registers. It's beneficial to use them instead
> > of
> > instructions that operate on
1 - 100 of 130 matches
Mail list logo
