Hi all,
On 18/09/18 00:00, Ramana Radhakrishnan wrote:
On Mon, 17 Sep 2018, 23:56 Christophe Lyon,
wrote:
> On Fri, 14 Sep 2018 at 12:04, Sam Tebbs wrote:
> >
> >
> >
> > On 08/28/2018 11:54 PM, James Greenhalgh wrote:
> >
> >
> > >
> > > OK once the other one is approved, with the obvious r
On Mon, 17 Sep 2018, 23:56 Christophe Lyon,
wrote:
> On Fri, 14 Sep 2018 at 12:04, Sam Tebbs wrote:
> >
> >
> >
> > On 08/28/2018 11:54 PM, James Greenhalgh wrote:
> >
> >
> > >
> > > OK once the other one is approved, with the obvious rebase over the
> renamed
> > > function.
> > >
> > > James
On Fri, 14 Sep 2018 at 12:04, Sam Tebbs wrote:
>
>
>
> On 08/28/2018 11:54 PM, James Greenhalgh wrote:
>
>
> >
> > OK once the other one is approved, with the obvious rebase over the renamed
> > function.
> >
> > James
>
> Here is the rebased patch. Still OK for me to commit to trunk now that
> t
On 08/28/2018 11:54 PM, James Greenhalgh wrote:
OK once the other one is approved, with the obvious rebase over the renamed
function.
James
Here is the rebased patch. Still OK for me to commit to trunk now that
the other patch has been committed?
Sam
gcc/
2018-07-31 Sam Tebbs
On Tue, Jul 31, 2018 at 04:38:43AM -0500, Sam Tebbs wrote:
> Hi all,
>
> This patch captures the case where an unnecessary uxtw instruction is
> generated
> after a bfxil instruction when in SI mode, and stops it from being
> generated.
> Note that this depends on my previous patch submission
>
Hi all,
This patch captures the case where an unnecessary uxtw instruction is
generated
after a bfxil instruction when in SI mode, and stops it from being
generated.
Note that this depends on my previous patch submission
(https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01148.html).
For example:
