From: Sören Tempel
The .regs member is primarily intended to be used in conjunction with
ptrace. Since this code is not using ptrace, using .regs is a bad idea.
Furthermore, the code currently fails to compile on musl since the
pt_regs type (used by .regs) is in an incomplete type which has to be
Met some problem in git send-email --cc=a,b,c, so manually CC.
On Mon, Mar 7, 2022 at 1:11 PM liuhongt via Gcc-patches
wrote:
>
> >What happens if you set preferred_for_speed to false for alternative 1?
> It works, and I've removed the newly added splitter in this patch.
> Also i tried to do simi
>What happens if you set preferred_for_speed to false for alternative 1?
It works, and I've removed the newly added splitter in this patch.
Also i tried to do similar things to *vec_dup with mode iterator
AVX2_VEC_DUP_MODE, but it hit ICE during reload since x86 don't have direct
move for QImode
Hi, Richard:
Thanks for your review.
We will revise it as soon as possible and submit it in the next version.
在 2022/3/7 上午12:16, Richard Sandiford 写道:
Hi,
Some comments below, but otherwise it looks good to me.
xucheng...@loongson.cn writes:
[…]
+(define_memory_constraint "k"
+ "A me
On Sat, Mar 5, 2022 at 4:05 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase ICEs, because the cond_andv* expander
> has vector_operand predicates in both of the commutative inputs
> and calls gen_andv*_mask which calls ix86_binary_operator_ok
> in its condition, but nothing calls ix86_f
On Sun, Mar 06, 2022 at 07:59:24PM +0100, soe...@soeren-tempel.net wrote:
> From: Sören Tempel
>
> The .regs member is primarily intended to be used in conjunction with
> ptrace. Since this code is not using ptrace, using .regs is a bad idea.
> Furthermore, the code currently fails to compile on
From: Sören Tempel
The .regs member is primarily intended to be used in conjunction with
ptrace. Since this code is not using ptrace, using .regs is a bad idea.
Furthermore, the code currently fails to compile on musl since the
pt_regs type (used by .regs) is in an incomplete type which has to be
> PR target/104781
> * config.host (tmake_file): Add i386/32/t-eh-return-no-sse for
> 32-bit x86 Cygwin and Solaris.
> * config/i386/32/t-eh-return-no-sse: New file.
What about MinGW here?
--
Eric Botcazou
On Sun, Mar 06, 2022 at 10:22:56AM -0500, Rich Felker wrote:
> On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
> wrote:
> > Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> > using uc_regs instead of regs, which does look correct to me.
>
> Yes, t
Hi,
Some comments below, but otherwise it looks good to me.
xucheng...@loongson.cn writes:
> […]
> +(define_memory_constraint "k"
> + "A memory operand whose address is formed by a base register and
> (optionally scaled)
> + index register."
> + (and (match_code "mem")
> + (not (match_
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-12.1-b20220213.sv.po'
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-12.1-b20220213.fr.po',
On Mon, Feb 21, 2022 at 09:25:43AM -0800, Ian Lance Taylor via Gcc-patches
wrote:
> Note for gofrontend-dev: on gcc-patches only Andreas Schwab suggested
> using uc_regs instead of regs, which does look correct to me.
Yes, this is absolutely the correct fix. Having pt_regs appear at all
in code n
What would be the benefit of using .uc_regs instead of .regs? The
current code works entirely fine as it, it just needs an include of the
Linux Kernel header defining the pt_regs type (which my proposed patch
adds).
Furthermore, it seems to me that .uc_regs is only available on powerpc
but not on
This updates gcc.dg/lower-subreg-1.c to reflect that the i386 backend now
lowers iordi3 itself, rather than relying on the middle-end's subreg1 pass.
Committed as obvious. Sorry for the noise; my "-m32 -march=cascadelake"
scripts were looking for regressions in gcc.target/i386 [now corrected].
On Mär 06 2022, Richard Sandiford via Gcc-patches wrote:
> Similarly here we need to avoid bash's $(...).
$(...) is 100% POSIX.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi,
Thanks for the submission. Some comments below on this patch,
but otherwise it looks good. I hope to get to the other patches
in the series soon.
I haven't followed all of the previous discussion, so some of these
points might already have been discussed. Sorry in advance if so.
xucheng..
On Sat, Mar 05, 2022 at 09:33:58AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for inde
18 matches
Mail list logo
