On 04/13/2018 05:26 PM, Segher Boessenkool wrote:
Hi!
On Fri, Apr 13, 2018 at 04:43:02PM -0400, Vladimir Makarov wrote:
On 04/13/2018 03:58 PM, Alexander Monakov wrote:
Here's another compact variant:
regno = reg_renumber[regno];
if (regno < 0)
regno = cl ==
Hi!
On Fri, Apr 13, 2018 at 04:43:02PM -0400, Vladimir Makarov wrote:
> On 04/13/2018 03:58 PM, Alexander Monakov wrote:
> >Here's another compact variant:
> >
> > regno = reg_renumber[regno];
> > if (regno < 0)
> > regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
> >
>
On 04/13/2018 03:58 PM, Alexander Monakov wrote:
On Fri, 13 Apr 2018, Jakub Jelinek wrote:
if (reg_renumber[regno] >= 0)
regno = reg_renumber[regno];
else
regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
or
regno = (reg_renumber[reg
On Fri, 13 Apr 2018, Jakub Jelinek wrote:
> if (reg_renumber[regno] >= 0)
> regno = reg_renumber[regno];
> else
> regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
> or
> regno = (reg_renumber[regno] >= 0
> ? reg_renumber[regno]
>
On Fri, Apr 13, 2018 at 03:29:47PM -0400, Vladimir Makarov wrote:
> The attached patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
>
> The PR is about LRA cycling on some tests when SD data are used. The
> problem was in that actual assigned reg to pseudo was not in the pseu
The attached patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
The PR is about LRA cycling on some tests when SD data are used. The
problem was in that actual assigned reg to pseudo was not in the pseudo
preferred class and this resulted in wrong generated code which LRA
tri
On Tue, Jun 5, 2012 at 3:13 PM, Edmar wrote:
> The patch I submitted had an omission. I failed to regenerate
> rs6000-tables.opt
> (Sorry, I misunderstood gcc_update --touch instructions)
> OK to commit the update ?
>
> 2012-06-05 Edmar Wienskoski
>
> * config/rs6000/rs6000-tables.opt: Regene
The patch I submitted had an omission. I failed to regenerate
rs6000-tables.opt
(Sorry, I misunderstood gcc_update --touch instructions)
OK to commit the update ?
2012-06-05 Edmar Wienskoski
* config/rs6000/rs6000-tables.opt: Regenerated.
On 06/04/2012 08:45 PM, David Edelsohn wrote:
T
On Fri, Jun 1, 2012 at 11:57 AM, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
>
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description, and set proper default flags for the e5500 and e6500 cores.
>
> Some Altivec extensions for e6500 wil
Freescale would like to contribute these patches to gcc.
It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
description, and set proper default flags for the e5500 and e6500 cores.
Some Altivec extensions for e6500 will be submitted as a separate process.
The patch was reg
On Wed, May 23, 2012 at 10:18 AM, Edmar wrote:
> David, Michael,
>
> Thanks for the feedback.
> If you don't object, I will relay the message to the designers.
>
> Meanwhile I have to work with the cards I have, so...
> I will break the patch in three parts:
> - One that includes the very basic, s
David, Michael,
Thanks for the feedback.
If you don't object, I will relay the message to the designers.
Meanwhile I have to work with the cards I have, so...
I will break the patch in three parts:
- One that includes the very basic, scheduling etc.
- One for the Altivec builtins, which I will h
> Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has
> dedicated masks on target_flags for them, but due to shortage of bits,
> those masks controls more than the name implies.
The target flag bits control more than the name implies, but the bits
correspond to published ISA levels
Michael,
Thanks for reviewing the patch and all the suggestions.
I have some questions / comments bellow.
Regards,
Edmar
On 05/17/2012 06:16 PM, Michael Meissner wrote:
In the patch I minimized the number of changes, while not adding
any new mask to target_flags.
While we may get some bits
On Tue, Mar 06, 2012 at 11:44:08AM -0500, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
>
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description, and set proper default flags for the e5500 and e6500 cores.
>
> Both are 64 bit cores capa
Joseph,
Thanks for the tip.
It is likely I need to re-generate the patch (and re-test)
as there had been a lot of activity in the trunk since the original post.
I will do this soon.
Regards,
Edmar
On 05/16/2012 11:10 AM, Joseph S. Myers wrote:
On Fri, 16 Mar 2012, Edmar wrote:
I am pingin
On Fri, 16 Mar 2012, Edmar wrote:
> I am pinging this post:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00430.html
I don't see any sign of anything further having happened with this patch
... you should ping approximately weekly until a patch is reviewed, and
probably also CC relevant mai
I am pinging this post:
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00430.html
Thanks
Edmar
On 04/20/2011 07:52 PM, Segher Boessenkool wrote:
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -y) is always a mask with one bit set, which corresponds
to the least significant "1" bit in y.
The final result is that bit, is set to zero (y & ~mask)
There is no bo
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -y) is always a mask with one bit set, which corresponds
to the least significant "1" bit in y.
The final result is that bit, is set to zero (y & ~mask)
There is no boolean simplification possible, and the compiler alw
This patch fixes some test cases for PowerPC.
The tests pr39902-2.c, dfp-dd.c, and dfp-td.c reports as errors
when gcc is configured without dfp support. This patch will make the
tests to be reported as unsupported.
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -
21 matches
Mail list logo
