On Sun, 4 May 2025, John Paul Adrian Glaubitz wrote:
> > > What exactly is broken with the QEMU emulation in Alpha? I don't know of
> > > any
> > > bugs, but it could be that you have run into the nasty stack alignment
> > > issue
> > > in the kernel that was fixed in Linux 6.14.
> >
> > This
Hi Maciej,
On Sun, 2025-05-04 at 12:11 +0100, Maciej W. Rozycki wrote:
> > What exactly is broken with the QEMU emulation in Alpha? I don't know of any
> > bugs, but it could be that you have run into the nasty stack alignment issue
> > in the kernel that was fixed in Linux 6.14.
>
> This was wi
On Sun, 4 May 2025, John Paul Adrian Glaubitz wrote:
> > I only have non-BWX hardware and I'm not interested in decommissioning it
> > or upgrading. There appear to be a few users around, but I seem to be the
> > last GCC developer remaining who is willing to do anything about the port.
> >
Hi Andrew,
On Sat, 2025-05-03 at 22:32 -0700, Andrew Pinski wrote:
> > PPS: Sorry for posting out of thread, but unlike lore.kernel.org, I could
> > not find a way to obtain the message or mboxes on gcc-patches.
>
> https://inbox.sourceware.org/gcc-patches/ is the link to the official
> publ
Hi Maciej,
On Fri, 2025-05-02 at 17:27 +0100, Maciej W. Rozycki wrote:
> I only have non-BWX hardware and I'm not interested in decommissioning it
> or upgrading. There appear to be a few users around, but I seem to be the
> last GCC developer remaining who is willing to do anything about the
Hi Maciej,
On Fri, 2025-05-02 at 11:57 +0100, Maciej W. Rozycki wrote:
> - I have only learnt last year that the Alpha backend also needs some work
> here and it appears that it relies on a hack or a bunch within reload to
> propagate alignment information required for non-BWX targets to pro
John Paul Adrian Glaubitz writes:
> Hello,
>
>
>
>
>> This mini-series removes the TARGET_LRA_P hook, forcing all targets
>> to use LRA. I have not touched the targets that define -mlra
>> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
>> "default" that. I'd expect those to wrong
Hello,
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect those to wrongly assume LRA isn't enabled
> when using that XXX
On Sat, May 3, 2025 at 10:29 PM John Paul Adrian Glaubitz
wrote:
>
> Hello,
>
>
>
>
> > This mini-series removes the TARGET_LRA_P hook, forcing all targets
> > to use LRA. I have not touched the targets that define -mlra
> > in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> > "defau
Hello,
> This mini-series removes the TARGET_LRA_P hook, forcing all targets
> to use LRA. I have not touched the targets that define -mlra
> in terms of a 'Target Mask(XXX)' since IIRC there's no way to
> "default" that. I'd expect those to wrongly assume LRA isn't enabled
> when using that
On Sat, 3 May 2025, Paul Koning wrote:
> > As for MEM(MEM(xyz)) addressing modes I'm less sure - I suppose those
> > are usually formed at RTL expansion time (rather than, say, by
> > RTL combine)? If PDP-11 is the only target with those then it might
> > be easier to recover those post-LRA durin
> On May 3, 2025, at 6:52 AM, Richard Biener wrote:
>
> On Fri, 2 May 2025, Paul Koning wrote:
>
>>
>>
>>> On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
>>>
>>> ...
>>> NB I understand your position and the need to cut the line sometime, and
>>> I knew what the situation is with
On 5/3/25 4:52 AM, Richard Biener wrote:
On Fri, 2 May 2025, Paul Koning wrote:
On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
...
NB I understand your position and the need to cut the line sometime, and
I knew what the situation is with the VAX backend and that it would be
manag
On Fri, 2 May 2025, Paul Koning wrote:
>
>
> > On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
> >
> > ...
> > NB I understand your position and the need to cut the line sometime, and
> > I knew what the situation is with the VAX backend and that it would be
> > manageable. In princip
> On May 2, 2025, at 12:27 PM, Maciej W. Rozycki wrote:
>
> ...
> NB I understand your position and the need to cut the line sometime, and
> I knew what the situation is with the VAX backend and that it would be
> manageable. In principle it might be that it's only that single ICE that
> n
On Fri, 2 May 2025, Richard Biener wrote:
> > All in all I do keep the switch to LRA in mind and maybe I'll be able to
> > move forward in the GCC 16 development cycle after all, but all I can do
> > is entirely in my free time and that seems to be very limited recently and
> > plagued with em
On Fri, 2 May 2025, Richard Biener wrote:
> I'd appreciate target maintainers of targets with a -mlra to
> enable LRA by default and unconditionally (aka, remove -mlra)
> themselves. Eventually that work will be done in a more-or-less
> unchecked way later.
I do appreciate the desire to remove
On Fri, 2 May 2025, Maciej W. Rozycki wrote:
> On Fri, 2 May 2025, Richard Biener wrote:
>
> > I'd appreciate target maintainers of targets with a -mlra to
> > enable LRA by default and unconditionally (aka, remove -mlra)
> > themselves. Eventually that work will be done in a more-or-less
> > un
This mini-series removes the TARGET_LRA_P hook, forcing all targets
to use LRA. I have not touched the targets that define -mlra
in terms of a 'Target Mask(XXX)' since IIRC there's no way to
"default" that. I'd expect those to wrongly assume LRA isn't enabled
when using that XXX flag. Likewise
19 matches
Mail list logo
