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:
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
Same kind of issue in signal_64.c now.
The following patch fixes it:
This time I confirm, with the two above mentioned patches, it builds OK
with 4.9, see
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.