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://gcc.gnu.org/pipermail/gcc-patches/2021-April/568771.html
> v1 -> v2: Use the UNSPEC pattern, which is less efficient
On 5/3/21 1:09 PM, Ilya Leoshkevich wrote:
> 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 no
On 5/6/21 9:56 AM, Marius Hillenbrand wrote:
> Hi,
>
> this patch fixes the check of immediate operands to the builtin vec_permi and
> adds a new test for this built-in.
>
> Reg-rested and bootstrapped on s390x.
>
> Is it OK for master? Is it OK for backporting to gcc-11?
>
> Regards,
> Marius
On 5/4/21 5:08 PM, Robin Dapp wrote:
> Hi,
>
> instead of selecting bits 62 to (wraparound) 59 from r2 and inserting
> them into r3, we select bits 60 to 62 from r3 and insert them into r2
> nowadays. Adjust the test accordingly.
>
> Is this OK?
>
> Regards
> Robin
>
> gcc/testsuite/Change
Hi Robin,
On 5/5/21 5:18 PM, Robin Dapp wrote:
...
> diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
> index c80d582a300..7c730432d80 100644
> --- a/gcc/config/s390/vector.md
> +++ b/gcc/config/s390/vector.md
> @@ -36,6 +36,7 @@
> (define_mode_iterator V_HW2 [V16QI V8HI V4SI V
Ping
On 4/30/21 8:32 AM, Andreas Krebbel via Gcc-patches wrote:
> The problem appears to be triggered by two locations in the front-end
> where non-POINTER_SIZE pointers aren't handled right now.
>
> 1. An assertion in strip_typedefs is triggered because the alignment
> of t
v1 -> v2: build_reference_type_for_mode and build_pointer_type_for_mode now
pick pointer mode if
MODE argument is VOIDmode.
Bootstrapped and regression tested on x86_64 and s390x.
Ok for mainline and GCC 11?
Andreas
gcc/cp/ChangeLog:
PR c++/100281
* cvt.c (cp_convert_to_point
_Bool needs to be defined as macro in order to trigger the
context-sensitive macro expansion mechanism.
Bootstrapped and regtested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define
_Bool as macro expanding to _Bool.
Hi,
I need a way to save registers on the stack and generate proper CFI for it.
Since I do not intend to
restore them I needed a way to tell the CFI generation step about it:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606128.html
Is this ok for mainline?
Bye,
Andreas
Committed to mainline. Bootstrap and regression tests are clean.
gcc/ChangeLog:
* config/s390/s390.cc (s390_register_info): Check call_used_regs
instead of hard-coding the register numbers for call saved
registers.
(s390_optimize_register_info): Likewise.
gcc/test
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390.md (*not): New pattern.
gcc/testsuite/ChangeLog:
* gcc.target/s390/not.c: New test.
---
gcc/config/s390/s390.md | 8
gcc/testsuite/gcc.target/s390/not.c
On 12/27/22 19:23, Jeff Law wrote:
>
>
> On 12/13/22 01:55, Andreas Krebbel via Gcc-patches wrote:
>> Hi,
>>
>> I need a way to save registers on the stack and generate proper CFI for it.
>> Since I do not intend to
>> restore them I needed a way t
On 8/21/23 17:58, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390-builtins.def (s390_vec_signed_flt): Fix
> builtin flag.
> (s390_vec_unsigned_flt): Ditto.
> (s390_vec_revb_flt): Ditto.
>
Hi Stefan,
do you really need to introduce a new flag for U64 given that the type of the
builtin is unsigned long?
Andreas
On 8/21/23 17:56, Stefan Schulze Frielinghaus wrote:
> The second argument of these builtins is an unsigned immediate. For
> vec_rli the API allows immediates up to 64 bit
On 9/11/23 08:56, Stefan Schulze Frielinghaus wrote:
> On Mon, Aug 28, 2023 at 11:33:37AM +0200, Andreas Krebbel wrote:
>> Hi Stefan,
>>
>> do you really need to introduce a new flag for U64 given that the type of
>> the builtin is unsigned long?
>
> In f
For the testcase a symbol with a TLS reloc and an unary minus is being
generated. The backend didn't handle this correctly.
In s390_cannot_force_const_mem an unary minus on a symbolic constant
is rejected now since gas would not allow this.
legitimize_tls_address now makes the NEG rtx the outerm
The testcase failed because our backend refuses to generate vector
compare instructions for signaling operators with -fno-trapping-math
-fno-finite-math-only.
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
PR target/96456
* config/s390/s390.h
On 15.07.20 17:53, Stefan Schulze Frielinghaus wrote:
> 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
On 15.07.20 17:53, Stefan Schulze Frielinghaus wrote:
> 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
On 09.07.20 09:35, Stefan Schulze Frielinghaus wrote:
> 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 A
On 09.07.20 09:29, Stefan Schulze Frielinghaus wrote:
> 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
In s390_expand_insv the movstrict patterns are always generated with a
CC clobber although only movstricthi actually needs one. The patch
invokes the expanders instead of constructing the pattern by hand.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
modifier was plain
wrong: "sub3" and "ior_not3". Fortunately it never had any effect.
Bootstrapped and regression tested on s390x.
SPEC binaries built with and without the patch are identical.
gcc/ChangeLog:
2020-04-02 Andreas Krebbel
* config/s390/vect
From: Jim Johnston
Check for and handle new skip trace addresses when unwinding on zTPF.
libgcc/ChangeLog:
2020-04-03 Jim Johnston
* config/s390/tpf-unwind.h (MIN_PATRANGE, MAX_PATRANGE)
(TPFRA_OFFSET): Macros removed.
(CP_CNF, cinfc_fast, CINFC_CMRESET, CINTFC_CMCEN
On 07.04.20 09:59, Iain Buclaw wrote:
> On 01/04/2020 18:20, Stefan Liebler wrote:
>> 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
>>
On 07.04.20 18:26, Iain Buclaw wrote:
>
>
> On 07/04/2020 16:33, Stefan Liebler wrote:
>> 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 s
fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!
Bootstrapped and regression-tested on IBM z15.
gcc/ChangeLog:
2020-04-17 Andreas Krebbel
PR target/
-04-20 Andreas Krebbel
* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.
gcc/testsuite/ChangeLog:
2020-04-20 Andreas Krebbel
* g++.dg/pr94666.C: New test.
---
gcc/ChangeLog
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,
> Stefan
>
> gcc/ChangeLog:
>
> 2020-04-21 Stefan Schulze Frielinghaus
>
> * config/s390/s390.md ("*_ior_and_sr_ze"): li
On 26.04.20 14:20, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
> on s390x-linux.
>
> Bootstrapped/regtested on s390x-linux without and with the patch, the
> difference being:
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_alt.o
On 27.04.20 09:36, Jakub Jelinek wrote:
> On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote:
>> Ok. Thanks for doing this!
>
> Thanks, committed.
>
>> We probably have to look into providing a -Wpsabi warning as well.
>
> So like this? Untes
On 28.04.20 14:13, Jakub Jelinek wrote:
> Hi!
>
> So, based on the yesterday's discussions, similarly to powerpc64le-linux
> I've done some testing for s390x-linux too.
>
> First of all, I found a bug in my patch from yesterday, it was printing
> the wrong type like 'double' etc. rather than the
load the full vector. If it can be
recognized that it is in effect a full vector register load or store
it is now implemented with vl/vst instead.
I'll commit it to mainline after successful bootstrap and regtest.
gcc/ChangeLog:
2020-04-29 Andreas Krebbel
* config/s390/constrain
On 28.04.20 17:44, Jakub Jelinek wrote:
> On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel via Gcc-patches
> wrote:
>> Given that this is something which hasn't been covered by the ABI so far I'm
>> not sure we really need
>> a -Wpsabi warning for th
On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote:
>>
>> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>>>
>>> Btw, does s390 have different inlining parameters somehow?
>> I think so. We saw a ton of backend warni
On 30.04.20 18:33, Richard Biener wrote:
> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel wrote:
>>
>> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
>>> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote:
>>>>
>>>> On Tue, 2020-04-28 at 1
On 04.05.20 09:27, Richard Biener wrote:
> On Mon, May 4, 2020 at 8:14 AM Andreas Krebbel wrote:
>>
>> On 30.04.20 18:33, Richard Biener wrote:
>>> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel
>>> wrote:
>>>>
>>>> On 30.04.20 08:25, R
2020-05-08 Andreas Krebbel
* explow.c (anti_adjust_stack_and_probe_stack_clash): Remove
prototype. Remove static.
* explow.h (anti_adjust_stack_and_probe_stack_clash): Add
prototype.
* config/s390/s390.md ("allocat
-05-14 Andreas Krebbel
* config/s390/s390.c (allocate_stack_space): Add missing updates
of last_probe_offset.
gcc/testsuite/ChangeLog:
2020-05-14 Andreas Krebbel
* gcc.target/s390/stack-clash-1.c: New test.
---
gcc/ChangeLog | 5
Probes emitted by the common code routines still use a store. Define
the "probe_stack" pattern to use a compare instead.
Bootstrapped and regression tested on s390x
Committed to mainline
gcc/ChangeLog:
2020-05-14 Andreas Krebbel
* config/s390/s390.c (s390_emit_stack_pr
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
> still legal. Thus, emit alignment hints also for z13 targets so that if
> the binary is actually
On 1/5/21 7:37 PM, Ilya Leoshkevich wrote:
> 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 alway
On 1/8/21 1:17 AM, Ilya Leoshkevich wrote:
> + s390_def_or_undef_macro (
> + pfile,
> + [] (const struct cl_target_option *opts) { return TARGET_Z14_P (opts);
> },
> + old_opts, opts, "__LONG_DOUBLE_VX__", "__LONG_DOUBLE_VX__");
Shouldn't this rather check TARGET_VXE_P instead?
On 1/8/21 2:14 PM, Ilya Leoshkevich wrote:
> 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 ve
On 1/8/21 5:35 PM, Ilya Leoshkevich wrote:
> 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/vect
of the vector -
in this case the zeroes.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2021-01-11 Andreas Krebbel
* tree-ssa-forwprop.c (simplify_vector_constructor): For
big-endian, use UNPACK[_FLOAT]_HI.
---
gcc/tree-ssa-forwprop.c | 21 +--
On 16.06.20 10:26, Stefan Schulze Frielinghaus wrote:
> 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 o
IBM z15.
Committed to mainline.
2020-06-17 Andreas Krebbel
gcc/
* config/s390/s390.c (s390_fix_long_loop_prediction): Exit early
for PARALLELs.
gcc/testsuite/
* gcc.target/s390/20200617.c: New test.
---
gcc/config/s390/s390.c | 9 +++--
gcc
On 01.07.20 14:29, Ilya Leoshkevich wrote:
...
> 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 Leosh
On 23.11.20 22:38, Ilya Leoshkevich wrote:
> 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:
On 24.11.20 12:55, Ilya Leoshkevich wrote:
> 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 supporte
On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Historically, float_t has been defined as double on s390 and gcc would
> emit double precision insns for evaluating float expressions when in
> standard-compliant mode. Configure that behavior at compile-time as prep
> for changes in glibc: When glib
On 11/25/20 6:06 PM, Marius Hillenbrand wrote:
> Add two test cases that check for acceptable combinations of float_t and
> FLT_EVAL_METHOD on s390x.
>
> Tested against an as-is glibc and one modified so that it derives
> float_t from FLT_EVAL_METHOD.
>
> gcc/testsuite/ChangeLog:
>
> 2020-11-25
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?
>
>
>
> Currently GCC loads large immediates into GPRs from the liter
On 12/2/20 4:08 PM, Ilya Leoshkevich wrote:
> 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 lo
The probe pattern uses Pmode but the middle-end wants to emit a
word_mode probe check. This - as usual - breaks on Z with -m31 -mzarch
were word_mode doesn't match Pmode.
Bootstrapped and regression-tested on s390x.
gcc/ChangeLog:
* config/s390/s390.md ("@probe_stack2"): Change mode
In s390.c we are still using Pmode for the stack probes. This breaks
with -m31 -mzarch where Pmode != word_mode.
The patch also adds a new target check to s390.exp which allows us to
implement zarch specific checks in the testcases.
Bootstrapped and regression tested on s390x with and without zar
On 12/3/20 2:22 AM, Ilya Leoshkevich wrote:
> 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
On 18.10.20 20:32, Stefan Schulze Frielinghaus wrote:
> 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
decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.
Bootstrapped and regression tested on IBM Z.
Committed to head, gcc-10, gcc-9, and gcc-8 branches.
gcc/ChangeLog:
PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
gen
The S/390 backend does not define vec_cmp expanders so far. We relied
solely on expanding vcond. With commit 502d63b6d various testcases
started to ICE now.
This patch just adds the missing expanders to prevent the ICE.
However, there are still a couple of performance-related testcase
regressions
After adding vec_cmp expanders we have seen various performance
related regression in the testsuite. These appear to be caused by a
missing vcond_mask definition in the backend. Fixed with this patch.
The patch fixes the following testsuite fails:
FAIL: gcc.dg/vect/vect-21.c -flto -ffat-lto-obj
This works around a limitation of gcse with handling of partially
clobbered registers. With this patch our GOT pointer register r12 is
not marked as partially clobbered anymore for the -m31 -mzarch -fpic
combination. This is correct since all the bits in r12 we actually
care about are in fact pres
dwarf2cfi from complaining about the register saves without restores.
Andreas Krebbel (2):
New reg note REG_CFA_NORESTORE
IBM zSystems: Save argument registers to the stack -mpreserve-args
gcc/config/s390/s390.cc | 263 +-
gcc/config/s390/s390.opt
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to b
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments.
With the -mpreserve-args option GPRs and FPRs are save to the stack
slots whic
On 1/24/23 09:47, Stefan Schulze Frielinghaus wrote:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
> https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
GPRs and FPRs are save to the stack
slots which are reserved for stdargs in the register save area.
The introduction of REG_CFA_NORESTORE is a common code change which
has been approved last year already.
Bootstrapped and regtested on s390x. Committed to mainline.
Andreas Krebbel (3):
New reg
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to b
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments without having to rely on debug information.
With the -mpreserve-args option GP
With this patch a scheduling barrier is created to prevent the insn
setting up the frame-pointer and instructions which save GPRs to the
stack to be swapped. Otherwise broken CFI information would be
generated since the stack save insns would use a base register which
is not currently declared as
gcc/ChangeLog:
* config/s390/s390.c (struct s390_processor processor_table):
Binutils name string must not be empty.
---
gcc/config/s390/s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index de48271d6d4..15
On 3/16/21 1:16 AM, Ilya Leoshkevich wrote:
> 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
On 3/30/21 12:43 PM, Jakub Jelinek wrote:
> Hi!
>
> These test FAIL on s390*:
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
> In function 'foo8':
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:71:1:
>
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok. Thanks!
Andreas
> ---
> gcc/config/s390/s390
This fixes the error checking for two of the vector builtins which
accept irregular (e.g. non-contigiuous) ranges of values.
Regression tested on s390x (--with-arch=arch13).
Applied to mainline. Needs to go into 9 and 10 branch as well.
gcc/ChangeLog:
* config/s390/s390-builtins.def (O_M
On 4/12/21 3:40 PM, Stefan Schulze Frielinghaus wrote:
> Bootstraped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
> alternative in order to load a DFP zero.
Ok, thanks!
Andreas
> ---
> gcc/config/s390/s390
On 4/16/21 3:59 PM, Robin Dapp wrote:
> Hi,
>
> checking for an osc break is somewhat brittle especially with many
> passes potentially introducing new insns and moving them around.
> Therefore, only run the test with -O1 -fschedule-insns in order to limit
> the influence of other passes.
Yeah, t
On 4/20/21 9:17 AM, Stefan Schulze Frielinghaus wrote:
> Depending on whether GCC is configured using --with-mode=zarch or not,
> for the 31bit target instructions are generated either for ESA or
> z/Architecture. For the sake of simplicity and robustness test only for
> the latter by adding manua
With the current handling of decl alignments it is impossible to
reduce the alignment requirement as part of a variable declaration.
This change has been proposed by Richard in the PR. It fixes the
align-1.c testcase on IBM Z.
Bootstrapped on x86_64 and s390x. No regressions.
Ok for mainline?
g
On 6/22/21 12:20 AM, Ilya Leoshkevich wrote:
> 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
On 6/24/21 12:42 AM, Ilya Leoshkevich wrote:
> 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 nop
The cprop_hardreg pass is built around the assumption that accessing a
register in a narrower mode is the same as accessing the lowpart of
the register. This unfortunately is not true for vector registers on
IBM Z. This caused a miscompile of LLVM with GCC 8.5. The problem
could not be reproduced
On 1/13/22 18:11, Andreas Krebbel via Gcc-patches wrote:
...
> @@ -5949,7 +5959,7 @@ register if floating point arithmetic is not being
> done. As long as the\n\
> floating registers are not in class @code{GENERAL_REGS}, they will not\n\
> be used unless some pattern's constr
On 1/14/22 08:37, Richard Biener wrote:
...
> Can the gist of this bug be put into the GCC bugzilla so the rev can
> refer to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
> Can we have a testcase even?
The testcase from Jakub is in the BZ. However, since it doesn't fail with head
I di
On 1/14/22 20:41, Andreas Krebbel via Gcc-patches wrote:
> On 1/14/22 08:37, Richard Biener wrote:
> ...
>> Can the gist of this bug be put into the GCC bugzilla so the rev can
>> refer to it?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>
>> Can we have a
1001 - 1086 of 1086 matches
Mail list logo
