On Wed, Aug 12, 2020 at 02:32:51PM +0200, Christophe Leroy wrote:
> Anyway, it seems that GCC doesn't make much use of the "m<>" and the
> pre-update form.
GCC does not use update form outside of inner loops much. Did you
expect anything else?
> Most of the benefit of flexible addressing seems
Le 08/07/2020 à 06:49, Christophe Leroy a écrit :
Le 07/07/2020 à 21:02, Christophe Leroy a écrit :
Le 07/07/2020 à 14:44, Christophe Leroy a écrit :
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Hi Michael,
I see this patch
Le 07/07/2020 à 21:02, Christophe Leroy a écrit :
Le 07/07/2020 à 14:44, Christophe Leroy a écrit :
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Hi Michael,
I see this patch is marked as "defered" in patchwork, but I can't see
Le 07/07/2020 à 14:44, Christophe Leroy a écrit :
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Hi Michael,
I see this patch is marked as "defered" in patchwork, but I can't see
any related discussion. Is it normal ?
Because it
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Hi Michael,
I see this patch is marked as "defered" in patchwork, but I can't see
any related discussion. Is it normal ?
Because it uses the "m<>" constraint which didn't work on GCC
Le 30/06/2020 à 23:18, Segher Boessenkool a écrit :
Hi again,
Thanks for your work so far!
On Tue, Jun 30, 2020 at 06:53:39PM +, Christophe Leroy wrote:
On 06/30/2020 04:33 PM, Segher Boessenkool wrote:
+ make -s CC=powerpc64-linux-gnu-gcc -j 160
In file included from
Hi again,
Thanks for your work so far!
On Tue, Jun 30, 2020 at 06:53:39PM +, Christophe Leroy wrote:
> On 06/30/2020 04:33 PM, Segher Boessenkool wrote:
> >>>+ make -s CC=powerpc64-linux-gnu-gcc -j 160
> >>>In file included from /linux/include/linux/uaccess.h:11:0,
> >>>
On 06/30/2020 04:33 PM, Segher Boessenkool wrote:
On Tue, Jun 30, 2020 at 04:55:05PM +0200, Christophe Leroy wrote:
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Because it uses the "m<>" constraint which didn't work on GCC 4.6.
On Tue, Jun 30, 2020 at 04:55:05PM +0200, Christophe Leroy wrote:
> Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
> >Michael Ellerman writes:
> >>Because it uses the "m<>" constraint which didn't work on GCC 4.6.
> >>
> >>https://github.com/linuxppc/issues/issues/297
> >>
> >>So we should be
Le 30/06/2020 à 03:19, Michael Ellerman a écrit :
Michael Ellerman writes:
Christophe Leroy writes:
Hi Michael,
I see this patch is marked as "defered" in patchwork, but I can't see
any related discussion. Is it normal ?
Because it uses the "m<>" constraint which didn't work on GCC
Michael Ellerman writes:
> Christophe Leroy writes:
>> Hi Michael,
>>
>> I see this patch is marked as "defered" in patchwork, but I can't see
>> any related discussion. Is it normal ?
>
> Because it uses the "m<>" constraint which didn't work on GCC 4.6.
>
>
Christophe Leroy writes:
> Hi Michael,
>
> I see this patch is marked as "defered" in patchwork, but I can't see
> any related discussion. Is it normal ?
Because it uses the "m<>" constraint which didn't work on GCC 4.6.
https://github.com/linuxppc/issues/issues/297
So we should be able to
Hi Michael,
I see this patch is marked as "defered" in patchwork, but I can't see
any related discussion. Is it normal ?
Christophe
Le 16/04/2020 à 14:39, Christophe Leroy a écrit :
At the time being, __put_user()/__get_user() and friends only use
D-form addressing, with 0 offset. Ex:
13 matches
Mail list logo
