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 <m...@ellerman.id.au> writes:
Christophe Leroy <christophe.le...@csgroup.eu> 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.


So we should be able to pick it up for v5.9 hopefully.

It seems to break the build with the kernel.org 4.9.4 compiler and

Most likely a GCC bug ?

It seems the problem vanishes with patch https://patchwork.ozlabs.org/project/linuxppc-dev/patch/173de3b659fa3a5f126a0eb170522cccd909950f.1594125164.git.christophe.le...@csgroup.eu/

Same kind of issue in signal_64.c now.

The following patch fixes it: https://patchwork.ozlabs.org/project/linuxppc-dev/patch/810bd8840ef990a200f58c9dea9abe767ca02a3a.1594146723.git.christophe.le...@csgroup.eu/

This time I confirm, with the two above mentioned patches, it builds OK with 4.9, see http://kisskb.ellerman.id.au/kisskb/head/810bd8840ef990a200f58c9dea9abe767ca02a3a/

I see you've merged those patches that make the issue disappear, yet not this patch yet. I guess you are still a bit chilly about it, so I split it in two parts for you to safely take patch 1 as soon as possible while handling the "m<>" constraint subject more carefully via https://github.com/linuxppc/issues/issues/297 in a later stage.

Anyway, it seems that GCC doesn't make much use of the "m<>" and the pre-update form. Most of the benefit of flexible addressing seems to be achieved with patch 1 ie without the "m<>" constraint and update form.


Reply via email to