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.
https://github.com/linuxppc/issues/issues/297
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
corenet64_smp_defconfig:
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.
Christophe
