Hi Roger!
Thanks for your patience! I very much know how it's frustrating...
I promise I'll get to your patches: in fact I already started looking
into these before the Cauldron, but ran into GCC/nvptx things that I
didn't understand but felt I need to understand/address first, then after
the Cau
Random fact: there have been no changes to nvptx.md in 2023 apart
from Jakub's tree-wide update to the copyright years in early January.
Please can I ping two of my of pending Nvidia nvptx patches:
"Correct pattern for popcountdi2 insn in nvptx.md" from January
https://gcc.gnu.org/pipermail/gcc
On Mon, Nov 8, 2021 at 4:40 PM Richard Biener
wrote:
>
> On Mon, Nov 8, 2021 at 3:02 PM Roger Sayle wrote:
> >
> >
> > Hi Richard,
> >
> > >> I wonder if reviewers could take a look (or a second look) at some of
> > >> my outstanding patches.
> > >> PR middle-end/100810: Penalize IV candidates wi
On Mon, Nov 8, 2021 at 3:02 PM Roger Sayle wrote:
>
>
> Hi Richard,
>
> >> I wonder if reviewers could take a look (or a second look) at some of
> >> my outstanding patches.
> >> PR middle-end/100810: Penalize IV candidates with undefined value
> >> bases
> >> https://gcc.gnu.org/pipermail/gcc-pat
Hi Richard,
>> I wonder if reviewers could take a look (or a second look) at some of
>> my outstanding patches.
>> PR middle-end/100810: Penalize IV candidates with undefined value
>> bases
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578441.html
>
> I did comment on this one, not
On Sat, Nov 6, 2021 at 11:21 PM Roger Sayle wrote:
>
>
> I wonder if reviewers could take a look (or a second look) at some of my
> outstanding patches.
>
> Four nvptx backend patches:
>
> nvptx: Use cvt to perform sign-extension of truncation.
> https://gcc.gnu.org/pipermail/gcc-patches/2021-Augu
>On 11/6/2021 4:20 PM, Roger Sayle wrote:
>> Simplify paradoxical subreg extensions of TRUNCATE
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html
> So the discussion seemed to end with a recommendation to try and address this
> earlier in the call chain rather than in simp
On 11/6/2021 4:20 PM, Roger Sayle wrote:
Simplify paradoxical subreg extensions of TRUNCATE
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html
So the discussion seemed to end with a recommendation to try and address
this earlier in the call chain rather than in simplify_rtx
I wonder if reviewers could take a look (or a second look) at some of my
outstanding patches.
Four nvptx backend patches:
nvptx: Use cvt to perform sign-extension of truncation.
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578256.html
nvptx: Add (experimental) support for HFmode with
The following patches are still awaiting review (longer than a week or two).
gfortran: Improve translation of POPPAR intrinsic
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548055.html
PR middle-end/90597: gcc_assert ICE in layout_type
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/5
James Greenhalgh writes:
> On Wed, Aug 30, 2017 at 04:34:40PM +0100, Richard Sandiford wrote:
>> Ping for a few AArch64 patches:
>>
>> [AArch64] Remove use of wider vector modes
>> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01249.html
>>
>> [AArch64] Rename cmp_result iterator
>>
On Wed, Aug 30, 2017 at 04:34:40PM +0100, Richard Sandiford wrote:
> Ping for a few AArch64 patches:
>
> [AArch64] Remove use of wider vector modes
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01249.html
>
> [AArch64] Rename cmp_result iterator
> https://gcc.gnu.org/ml/gcc-patc
Ping for a few AArch64 patches:
[61/77] Use scalar_int_mode in the AArch64 port
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00701.html
[75/77] Use scalar_mode in the AArch64 port
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00715.html
[AArch64] Remove use of wider vector m
Pinging patches #1 and #2 from the 4 part series to improve DSE. ISTM
that #3 and #4 should wait for gcc-7.
Patches #1 and #2 included for reference.
--- Begin Message ---
This is the first of the 4 part patchkit to address deficiencies in our
DSE implementation.
This patch addresses the
On Fri, Jan 16, 2015 at 7:05 AM, Jeff Law wrote:
> On 01/15/15 16:43, Nathaniel Smith wrote:
>>>
>>>
>>> Jakub, myself and management have discussed this issue extensively and
>>> those
>>> patches specifically. I'm painfully aware of how this affects the
>>> ability
>>> to utilize numerical pack
t; for a backend, language other than C or seemingly has another maintainer
>> that's engaged in review, then I haven't been tracking the patch.
>>
>> So this is my final call for patch pings. I've got some bandwidth and may
>> be able to look at a few patche
's a
patch
for a backend, language other than C or seemingly has another maintainer
that's engaged in review, then I haven't been tracking the patch.
So this is my final call for patch pings. I've got some bandwidth and may
be able to look at a few patches that have otherwise s
gt; > patch
> > for a backend, language other than C or seemingly has another maintainer
> > that's engaged in review, then I haven't been tracking the patch.
> >
> > So this is my final call for patch pings. I've got some bandwidth and may
> >
On 01/15/15 16:43, Nathaniel Smith wrote:
Jakub, myself and management have discussed this issue extensively and those
patches specifically. I'm painfully aware of how this affects the ability
to utilize numerical packages in Python.
Thanks for the response! I had no idea anyone was paying at
another maintainer
> that's engaged in review, then I haven't been tracking the patch.
>
> So this is my final call for patch pings. I've got some bandwidth and may
> be able to look at a few patches that have otherwise stalled.
Here is an ARM backend patch, CCing ARM m
t; tracking
>>> for gcc-5.However, note that I don't track everything. If it's a
>>> patch
>>> for a backend, language other than C or seemingly has another maintainer
>>> that's engaged in review, then I haven't been tracking the patch.
C or seemingly has another maintainer
that's engaged in review, then I haven't been tracking the patch.
So this is my final call for patch pings. I've got some bandwidth and may
be able to look at a few patches that have otherwise stalled.
I've been pinging this for about
another maintainer
> that's engaged in review, then I haven't been tracking the patch.
>
> So this is my final call for patch pings. I've got some bandwidth and may
> be able to look at a few patches that have otherwise stalled.
I've been pinging this for about a year
another maintainer
> that's engaged in review, then I haven't been tracking the patch.
>
> So this is my final call for patch pings. I've got some bandwidth and may
> be able to look at a few patches that have otherwise stalled.
>
This one was updated yesterday:
https://gcc
been
tracking the patch.
So this is my final call for patch pings. I've got some bandwidth and
may be able to look at a few patches that have otherwise stalled.
Jeff
Hello Everyone,
I would like to patch these two patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00408.html -- _Cilk_for
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00116.html -- SIMD enabled
functions for C++
They have been under review for a while now (~1 month)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/11 10:26, Bernd Schmidt wrote:
> On 04/15/2011 04:18 PM, Jeff Law wrote:
>
>> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html
>
> I don't know. I sympathize with the goal, but I'm not too happy about
> the structure of this patch. Do
On 04/15/2011 04:18 PM, Jeff Law wrote:
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html
I don't know. I sympathize with the goal, but I'm not too happy about
the structure of this patch. Doesn't this do the scan once for every
reload in an insn? It seems to me like the loop (or rather,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01060.html
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02247.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAg
29 matches
Mail list logo
