On Wed, 24 Nov 2021, Richard Biener wrote:
> > > All my concerns have been addressed. This is fine for the trunk. Thanks
> > > for
> > > your patience & explanations.
> >
> > Thank you for your review, I have committed this change to trunk now.
> >
> > Richard, OK for GCC 11 (correcting a VA
On Wed, 24 Nov 2021, Maciej W. Rozycki wrote:
> On Tue, 23 Nov 2021, Jeff Law wrote:
>
> > > Let me know if it clears your concerns and whether there's anything else
> > > you want me to retrieve from that GDB session.
> > Thanks for the clarifications. I never would have guessed that we could
On Tue, 23 Nov 2021, Jeff Law wrote:
> > Let me know if it clears your concerns and whether there's anything else
> > you want me to retrieve from that GDB session.
> Thanks for the clarifications. I never would have guessed that we could get
> into that code in the way you've described, but be
On 11/10/2021 9:41 AM, Maciej W. Rozycki wrote:
It's actually hunk #2 that fixes this specific ICE. The other two are
just a consequence: #3 just being a commutative variant of the same case
and #1 from observing that the rtx may now have changed if an ASHIFT too.
Are we getting into find
On Mon, 8 Nov 2021, Maciej W. Rozycki wrote:
> On Sun, 7 Nov 2021, Hans-Peter Nilsson wrote:
> > (I thought you'd use 6cb68940dcf9 and do the same for VAX.)
>
> I could, easily, but being confined to gcc/config/cris I don't expect it
> to be included in the build let alone trigger anything.
There
On Mon, 8 Nov 2021, Jeff Law wrote:
> > Well, the context of this code (around and including hunk #1) is:
> >
> >else if (insn_extra_address_constraint
> >(lookup_constraint (constraints[i])))
> > {
> > address_operand_reloaded[i]
> > = find_reloads_address
On Mon, 8 Nov 2021, Hans-Peter Nilsson wrote:
> I regression-tested this patch for cris-elf at
> r12-4987-g14e355df3053. No regressions compared to
> r12-4987-g14e355df3053. (JFTR, that's at regress-11,
> compared to T0=2007-01-05-16:47:21).
Great, thanks!
Maciej
On Sun, 7 Nov 2021, Maciej W. Rozycki wrote:
> For the record the change does fix numerous regressions in GCC 11 too,
> e.g.:
>
> === gcc Summary ===
>
> # of expected passes 122244
> # of unexpected failures 1852
> # of expected passes 122428
> # of unexpe
On 11/4/2021 6:18 PM, Maciej W. Rozycki wrote:
On Thu, 4 Nov 2021, Jeff Law wrote:
Sometimes the language we're using in email is not as crisp as it should be. So
just to be clear, the canonicalization I'm referring to is only in effect within
a MEM. It does not apply to address calculatio
> From: "Maciej W. Rozycki"
> Date: Wed, 3 Nov 2021 14:53:58 +0100
> gcc/
> PR middle-end/103059
> * reload.c (find_reloads_address_1): Also accept the ASHIFT form
> of indexed addressing.
> (find_reloads): Adjust accordingly.
> ---
> gcc/reload.c |9 ++---
> From: "Maciej W. Rozycki"
> Date: Wed, 3 Nov 2021 14:53:58 +0100
> gcc/
> PR middle-end/103059
> * reload.c (find_reloads_address_1): Also accept the ASHIFT form
> of indexed addressing.
> (find_reloads): Adjust accordingly.
> ---
> gcc/reload.c |9 ++---
On Sun, 7 Nov 2021, Hans-Peter Nilsson wrote:
> > How do I run regression-testing with this target however? I can see QEMU
> > support upstream, even for user-mode Linux, which would be the easiest to
> > run (sadly toolchain support for CRIS/Linux was removed a while ago as was
> > the Linux ke
On Sun, 7 Nov 2021, Maciej W. Rozycki wrote:
> On Fri, 5 Nov 2021, Hans-Peter Nilsson wrote:
>
> > > I was trying to chase another target I could use to regression-test this
> > > with that does do scaled indexed addressing while still using old reload.
> > > The i386 port would be a good candidat
On Wed, 3 Nov 2021, Maciej W. Rozycki wrote:
> I have not yet tracked down which change after commit c605a8bf9270 made
> regressions appear in the test suites, however clearly the commit wasn't
> as complete a change as it should have been. I'll see if I can find it
> and will mention it in t
On Fri, 5 Nov 2021, Hans-Peter Nilsson wrote:
> > I was trying to chase another target I could use to regression-test this
> > with that does do scaled indexed addressing while still using old reload.
> > The i386 port would be a good candidate, but it has switched to LRA long
> > ago with no opt
On Wed, 3 Nov 2021, Maciej W. Rozycki wrote:
> Correct a `vax-netbsdelf' target regression ultimately caused by commit
> c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
> in jump threading registry.") c
On Thu, 4 Nov 2021, Jeff Law wrote:
> Sometimes the language we're using in email is not as crisp as it should be.
> So
> just to be clear, the canonicalization I'm referring to is only in effect
> within
> a MEM. It does not apply to address calculations that happen outside a MEM.
> I
> thi
On 11/4/2021 3:04 PM, Maciej W. Rozycki wrote:
On Thu, 4 Nov 2021, Jeff Law wrote:
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of com
On Thu, 4 Nov 2021, Jeff Law wrote:
> On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
> > Correct a `vax-netbsdelf' target regression ultimately caused by commit
> > c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> > LRA) and as of commit 4a960d548b7d ("Avoid invalid loop tr
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") ca
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.") causing a build error in libgcc:
.../libgcc/libgco
21 matches
Mail list logo
