Backporting gcc_qsort

[Cory Fields]

gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a
great change that defines the order of otherwise-unbalanced internal
sorts, some of which would otherwise cause bootstrapping failures.

I would like to request that these it as well as subsequent fixups
(all listed specifically below) be backported to the 8.x branch. They
apply cleanly to 8.x, and I can confirm that they fix qsort-related
bootstrap failures at least in my case of crossing x86_64-gnu to
x86_64-musl.

Would there be any downside to backporting?

The changes that I locally backported and tested successfully were:
r260216: Introduce gcc_qsort
r260222: gcc_qsort: avoid oversized memcpy temporaries
r262092: gcc_qsort: avoid overlapping memcpy (PR 86311)
r264065: qsort_chk: call from gcc_qsort instead of wrapping it

[0]: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00479.html

Regards,
Cory Fields

[Richard Biener]

Post by Cory Fields
gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a
great change that defines the order of otherwise-unbalanced internal
sorts, some of which would otherwise cause bootstrapping failures.
I would like to request that these it as well as subsequent fixups
(all listed specifically below) be backported to the 8.x branch. They
apply cleanly to 8.x, and I can confirm that they fix qsort-related
bootstrap failures at least in my case of crossing x86_64-gnu to
x86_64-musl.
Would there be any downside to backporting?

It is not something we generally backport.

Post by Cory Fields
r260216: Introduce gcc_qsort
r260222: gcc_qsort: avoid oversized memcpy temporaries
r262092: gcc_qsort: avoid overlapping memcpy (PR 86311)
r264065: qsort_chk: call from gcc_qsort instead of wrapping it
[0]: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00479.html
Regards,
Cory Fields

[Jeff Law]

Post by Richard Biener

Post by Cory Fields
gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a
great change that defines the order of otherwise-unbalanced internal
sorts, some of which would otherwise cause bootstrapping failures.
I would like to request that these it as well as subsequent fixups
(all listed specifically below) be backported to the 8.x branch. They
apply cleanly to 8.x, and I can confirm that they fix qsort-related
bootstrap failures at least in my case of crossing x86_64-gnu to
x86_64-musl.
Would there be any downside to backporting?

It is not something we generally backport.

To add a bit more context for Cory.

Generally backports are limited to fixing regressions and serious code
generation bugs. While we do make some exceptions, those are good
general guidelines.

I don't think the qsort changes warrant an exception.

jeff

[Alexander Monakov]

Post by Jeff Law
To add a bit more context for Cory.
Generally backports are limited to fixing regressions and serious code
generation bugs. While we do make some exceptions, those are good
general guidelines.
I don't think the qsort changes warrant an exception.

Personally I think in this case there isn't a strong reason to backport, the
patch is fairly isolated, so individuals or companies that need it should have
no problem backporting it on their own. Previously, Franz Sirl reported back
in June they've used the patch to achieve matching output on their Linux-hosted
vs Cygwin-hosted cross-compilers based on GCC 8:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00751.html

Alexander

[Cory Fields]

Understood. Thank you for the explanations.

I'll just plan to apply the patches locally as well.

Regards,
Cory

Post by Alexander Monakov

Post by Jeff Law
To add a bit more context for Cory.
Generally backports are limited to fixing regressions and serious code
generation bugs. While we do make some exceptions, those are good
general guidelines.
I don't think the qsort changes warrant an exception.

Personally I think in this case there isn't a strong reason to backport, the
patch is fairly isolated, so individuals or companies that need it should have
no problem backporting it on their own. Previously, Franz Sirl reported back
in June they've used the patch to achieve matching output on their Linux-hosted
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00751.html
Alexander