• Re: Testsuite failure on mips64el, solved with '-fno-inline'

    From Mathieu Malaterre@21:1/5 to haavard_aasen@yahoo.no on Mon Dec 6 15:10:01 2021
    Dear Håvard,

    On Mon, Dec 6, 2021 at 1:33 PM Håvard Flaget Aasen
    <haavard_aasen@yahoo.no> wrote:

    Hello,

    I've had some issues with the package c-blosc. The testsuite started
    to fail on mips64el. I found a solution, adding '-fno-inline' in
    CFLAGS in d/rules.

    Does this seem to be a valid solution or, does it only hide a problem
    with the source code?
    There are a couple of things I find strange, the testsuite only failed
    on mips64el and only after GCC-11 was the default compiler, (several
    other packages have also been updated), though it doesn't need to be
    related.

    I suspect that `-fno-inline` is simply not the right solution. Of
    course, the right solution would be for gcc-11 to properly compile the
    code, but I would suggest a slightly more specific solution in the
    meantime. I would suggest:

    ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips64el))
    CFLAGS+=-O1
    endif

    ^ -O1 will be added at the end of the compilation flags, and will
    override the current -02.

    If that works, we should forward the issue back to gcc people.

    Thanks for your work on c-blosc.

    -M

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to haavard_aasen@yahoo.no on Mon Dec 6 16:40:02 2021
    On Mon, Dec 6, 2021 at 7:33 AM Håvard Flaget Aasen
    <haavard_aasen@yahoo.no> wrote:

    Hello,

    I've had some issues with the package c-blosc. The testsuite started
    to fail on mips64el. I found a solution, adding '-fno-inline' in
    CFLAGS in d/rules.

    Does this seem to be a valid solution or, does it only hide a problem
    with the source code?
    There are a couple of things I find strange, the testsuite only failed
    on mips64el and only after GCC-11 was the default compiler, (several
    other packages have also been updated), though it doesn't need to be
    related.

    It sounds like something related to GCC 11. The release log does not
    show any behavior changes, see
    https://gcc.gnu.org/gcc-11/changes.html.

    Maybe the linker is performing the whole program optimization due to
    LTO and biting you. -fno-lto may help.

    If you can identify the function, then maybe you can be surgical and
    apply __attribute__((noinline)) to it.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)