Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
Commit 0990d93dd8a4 ("IBM Z: Use @PLT symbols for local functions in
64-bit mode") made GCC call both static and non-static functions and
load both static and non-static function addresses with the @PLT
suffix. This made it diffic
On Fri, 2025-01-24 at 17:25 +0100, Jakub Jelinek wrote:
> On Thu, Jan 09, 2025 at 01:15:30AM +0100, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
> >
> >
> >
> > The FakeStack flag is not zeroed out when can_st
On Thu, 2025-01-09 at 01:15 +0100, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
>
>
>
> The FakeStack flag is not zeroed out when can_store_by_pieces()
> returns false. Over time, this causes FakeStack::Allocate() to
>
.
gcc/ChangeLog:
* asan.cc (asan_emit_stack_protection): Always zero the flag
unless it is cleared by the __asan_stack_free_N() libcall.
Signed-off-by: Ilya Leoshkevich
---
gcc/asan.cc | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff
On Wed, 2024-09-11 at 16:44 +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote:
> > On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus
> > wrote:
> > > On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leosh
On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote:
> > On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus
> > wrote:
> > > On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leosh
On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote:
> > On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus
> > wrote:
> > > Currently subregs originating from *tf_to_fprx2_0
On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus wrote:
> Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
> survive register allocation. This in turn leads to wrong register
> renaming. Keeping the current approach would mean we need two insns
> for
> *tf_to_fpr
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 of DImode
> loads. Now, for the first load (wh
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.
---
libsanitizer/sanitizer_common/sanitizer_linux_s390.cpp |
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:
* gcc.target/s390/zvector/autovec-double-signaling-eq.c:
edict Glaw
Suggested-by: Jan-Benedict Glaw
Fixes: c659dd8bfb55 ("Implement ASM_DECLARE_FUNCTION_NAME using
ASM_OUTPUT_FUNCTION_LABEL")
Signed-off-by: Ilya Leoshkevich
gcc/ChangeLog:
* defaults.h (ASM_OUTPUT_FUNCTION_LABEL): Mark DECL as used.
---
gcc/defaults.h | 7 +-
ME using
ASM_OUTPUT_FUNCTION_LABEL")
Suggested-by: Jakub Jelinek
Signed-off-by: Ilya Leoshkevich
gcc/ChangeLog:
PR sanitizer/113284
* config/rs6000/rs6000.cc (rs6000_elf_declare_function_name):
Use assemble_function_label_final () for Power ELF V1 ABI.
On Tue, 2024-01-09 at 11:55 -0700, Jeff Law wrote:
>
>
> On 1/2/24 12:41, Ilya Leoshkevich wrote:
> > GCC can emit code between the function label and the .LASANPC
> > label,
> > making the latter unaligned. Some architectures cannot load
> > unaligned
> &
other branches already
use the correct macro.
Fixes: c659dd8bfb55 ("Implement ASM_DECLARE_FUNCTION_NAME using
ASM_OUTPUT_FUNCTION_LABEL")
Signed-off-by: Ilya Leoshkevich
gcc/ChangeLog:
PR sanitizer/113284
* config/rs6000/rs6000.cc (rs6000_elf_declare_function_name):
SANPC on function boundary")
Suggested-by: Jakub Jelinek
Signed-off-by: Ilya Leoshkevich
gcc/ChangeLog:
PR sanitizer/113251
* varasm.cc (assemble_function_label_raw): Do not call
asan_function_start () without the current function.
---
gcc/varasm.cc | 4 +++-
1 file
gccint recommends using ASM_OUTPUT_FUNCTION_LABEL in
ASM_DECLARE_FUNCTION_NAME, but many implementations use
ASM_OUTPUT_LABEL instead. It's inconsistent and prevents changes to
ASM_OUTPUT_FUNCTION_LABEL from affecting the respective targets.
---
gcc/config/aarch64/aarch64.cc | 2 +-
gcc/co
GCC can emit code between the function label and the .LASANPC label,
making the latter unaligned. Some architectures cannot load unaligned
labels directly and require literal pool entries, which is inefficient.
Move the invocation of asan_function_start to
ASM_OUTPUT_FUNCTION_LABEL, which guarant
338.html
[4] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html
[5] https://patchwork.ozlabs.org/project/gcc/list/?series=320223
[6] https://patchwork.ozlabs.org/project/gcc/list/?series=297132
[7] http://toolchain.lug-owl.de/laminar/jobs
Ilya Leoshkevich (2):
Implement ASM_DECLARE_F
GCC can emit code between the function label and the .LASANPC label,
making the latter unaligned. Some architectures cannot load unaligned
labels directly and require literal pool entries, which is inefficient.
Move the invocation of asan_function_start to
ASM_OUTPUT_FUNCTION_LABEL, which guarant
gccint recommends using ASM_OUTPUT_FUNCTION_LABEL in
ASM_DECLARE_FUNCTION_NAME, but many implementations use
ASM_OUTPUT_LABEL instead. It's inconsistent and prevents changes to
ASM_OUTPUT_FUNCTION_LABEL from affecting the respective targets.
---
gcc/config/aarch64/aarch64.cc | 2 +-
gcc/co
[3] https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html
[4] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html
[5] https://patchwork.ozlabs.org/project/gcc/list/?series=320223
[6] https://patchwork.ozlabs.org/project/gcc/list/?series=297132
[7] http://toolchain.lug-owl.de/laminar/
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/52506
(%r11)
gcc/ChangeLog:
2020-06-30 Ilya Leoshkevich
* config/s390/s390.h (CODE_LABEL_BOUNDARY): Specify that s390
requires code labels to be aligned on a 2-byte boundary.
gcc/testsuite/ChangeLog:
2019-06-30 Ilya Leoshkevich
* gcc.target/s390/asan-no-gotoff.c: New test
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
l the architectures
need to be adjusted, which looks like an overkill to me.
Best regards,
Ilya
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593666.html
Ilya Leoshkevich (2):
asan: specify alignment for LASANPC labels
IBM zSystems: Define CODE_LABEL_BOUNDARY
gcc/as
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?
> > >
> > >
> >
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,
>
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 copysign3
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 .r
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&#x
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
>
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
> > > https://p
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&#x
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 s
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 unnecessa
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 o
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
,
Ilya
Ilya Leoshkevich (2):
IBM Z: Define NO_PROFILE_COUNTERS
IBM Z: Use @PLT symbols for local functions in 64-bit mode
gcc/config/s390/predicates.md | 9 +-
gcc/config/s390/s390.c| 115 +++---
gcc/config/s390/s390.h
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 t
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.
* gcc.dg/
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, a
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.
* tree-ssa-reassoc
-ftree-vectorize, adjust expectations.
Ilya Leoshkevich (3):
reassoc: Do not bias loop-carried PHIs early
reassoc: Propagate PHI_LOOP_BIAS along single uses
reassoc: Test rank biasing
gcc/passes.def | 4 +-
gcc/testsuite/gcc.dg/tree-ssa/reassoc-46.c | 7 ++
gcc
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 o
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.
* gcc.dg/
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, a
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.
* tree-ssa-reassoc
lted in a significant code
simplification.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549149.html
Ilya Leoshkevich (3):
reassoc: Do not bias loop-carried PHIs early
reassoc: Propagate PHI_LOOP_BIAS along single uses
reassoc: Test rank biasing
gcc/passes
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 b/libsani
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.
* gcc.target/s390/
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 non-
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
> UN
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 non-
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 loc
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 ne
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 th
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:
> > https:/
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" sid
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. Chan
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)
> >
has. The whole change therefore
works only by accident.
Fix by looking at set_info's uses instead of insn_info's uses. This
requires passing around set_info instead of insn_info.
gcc/ChangeLog:
2021-03-02 Ilya Leoshkevich
* fwprop.c (fwprop_propagation::fwprop_pro
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_no
ires passing around set_info instead of insn_info.
gcc/ChangeLog:
2021-03-02 Ilya Leoshkevich
* fwprop.c (fwprop_propagation::fwprop_propagation): Look at
set_info's uses.
(try_fwprop_subst_note): Use set_info instead of insn_info.
(try_fwprop_subst_pattern
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
> >
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
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() alw
ok to convert TFmode values to
FPRX2mode and back.
gcc/ChangeLog:
2020-12-14 Ilya Leoshkevich
* config/s390/s390.c (f_constraint_p): New function.
(s390_md_asm_adjust): Implement TARGET_MD_ASM_ADJUST.
(TARGET_MD_ASM_ADJUST): Likewise.
* config/s390/vector
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.
> >
add input_modes parameter and document that it should be updated
whenever inputs parameter is updated.
gcc/ChangeLog:
2021-01-05 Ilya Leoshkevich
* cfgexpand.c (expand_asm_loc): Pass new parameter.
(expand_asm_stmt): Likewise.
* config/arm/aarch-common-protos.h (arm_md_asm_a
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.
---
_info::num_uses (), which in reality
returns the number of uses def's insn has. The whole change therefore
works only by accident.
Fix by looking at def_info's uses instead of insn_info's uses. This
requires passing around def_info instead of insn_info.
gcc/ChangeLog:
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 infinite
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 a/gcc/con
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 <-&
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
https://gcc.gnu.org/pipe
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
d with the former: long doubles
correspond to TFmode, which in combination with "f" corresponds to
hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair.
Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to
FPRX2mode and back.
gcc/ChangeLog:
2020-12-14 Ilya Leos
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 &outputs, vec &inputs,
> > + vec &input_modes,
> > +
g:FPRX2 66) (mem/c:FPRX2 (reg/v:DI 62)))
fwprop actually manages to perform this, but doesn't think the result is
worth it, which results in unnecessary store/load sequences on s390.
Improve the situation by classifying SUBREG -> MEM changes as
profitable.
gcc/ChangeLog:
2021-
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
https://gcc.gnu.org/pipe
is
worth it, which results in unnecessary store/load sequences on s390.
Improve the situation by classifying SUBREG -> MEM changes as
profitable.
gcc/ChangeLog:
2021-01-15 Ilya Leoshkevich
* fwprop.c (fwprop_propagation::classify_result): Allow
(subreg (mem)) simplificat
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 66) (subreg:FPRX2
as
profitable.
gcc/ChangeLog:
2021-01-15 Ilya Leoshkevich
* fwprop.c (fwprop_propagation::classify_result): Allow
(subreg (mem)) simplifications.
gcc/testsuite/ChangeLog:
2021-01-15 Ilya Leoshkevich
* gcc.target/s390/vector/long-double-to-i64.c: Expect that
d with the former: long doubles
correspond to TFmode, which in combination with "f" corresponds to
hard regs %v0-%v15, however, asm users expect a %f0-%f15 pair.
Fix by using TARGET_MD_ASM_ADJUST hook to convert TFmode values to
FPRX2mode and back.
gcc/ChangeLog:
2020-12-
erent offsets.
Fix by clearing all the cached data, and not just used_insn_alternative.
gcc/ChangeLog:
2021-01-13 Ilya Leoshkevich
* lra-spills.c (remove_pseudos): Call lra_update_insn_recog_data()
after calling alter_subreg() on a (mem).
---
gcc/lra-spills.c | 2 +-
1 file ch
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
asm statements.
gcc/ChangeLog:
2020-12-14 Ilya Leoshkevich
* config/s390/s390-c.c (s390_def_or_undef_macro): Accept
callables instead of mask values.
(struct target_flag_set_p): New predicate.
(s390_cpu_cpp_builtins_internal): Define or undef
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
ated.
gcc/ChangeLog:
2021-01-05 Ilya Leoshkevich
* cfgexpand.c (expand_asm_loc): Pass new parameter.
(expand_asm_stmt): Likewise.
* config/arm/aarch-common-protos.h (arm_md_asm_adjust): Add new
parameter.
* config/arm/aarch-common.c (arm_md_asm_adjust)
2020-12-10 Ilya Leoshkevich
* gcc.target/s390/s390.exp: Replace %% with %.
---
gcc/testsuite/gcc.target/s390/s390.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/s390/s390.exp
b/gcc/testsuite/gcc.target/s390/s390.exp
index ba493de9f95..5
m the Bugzilla and updated the
expectation. Does the following look better?
After 92648faa1cb2 ("aix: Fixinclude") make check-fixincludes began to
fail (at least on gcc121 machine). Fix by updating fixincludes/tests
and rerunning genfixes.
Co-developed-by: Nathan Sidwell
fixincludes/
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 L
1 - 100 of 302 matches
Mail list logo
