glibc 2.28 autopkgtest failures

[Michael Hudson-Doyle]

On Tue, 4 Sep 2018 at 13:26, Michael Hudson-Doyle <
michael.hudson at canonical.com> wrote:

> tl;dr we should force things through :)
>
> There are at the time of writing two autopkgtest failures preventing glibc
> from migrating: r-cran-rgenoud and python-cffi
>
> The r-cran-genoud failure is mystifying in that I have no idea how the
> glibc version is affecting the package (it doesn't call many libc or libm
> functions!). I've spent far too long trying on this but as the package has
> no rdeps we should probably just remove it and whoever brings it back can
> try to understand why it changes behaviour with new libc. (The test also
> looks a bit fragile, it is asserting that optimizing a particular function
> with the rng seeded a particular way finds a different maxima to seeding
> the rng a different way, afaict).
>
> The python-cffi is exposing a bug that exists already. A minimal failing
> example is this:
>

[...]


> The bug is that when you lie to cffi about the return type of a variable,
> in particular when you say a function returning a float does not return a
> float, the x87 stack is not wiped to the extent required by the calling
> convention. glibc 2.28 rewrote the cos function in a way that apparently
> now cares about this (or I guess gcc now compiles the function in a way
> that cares about this) but make no mistake, it only ever worked by chance
> before. So I think the test_sin_no_return_value test should be skipped on
> i386.
>

Unfortunately, python-cffi is now failing to build on ppc64el. Code like
this (where "source" is a double and target is a valid pointer):

    float r = (float)source;
    memcpy(target, &r, sizeof(float));

is getting compiled into code which doesn't call frsp (round to single
precision), which seems very wrong to me. It works if you compile it with
gcc-7 or with gcc-8 and no optimization. I've managed to reproduce it like
this:

(cosmic-ppc64el)root at diamond:/# cat u.c
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

char buf[4];

void write(double x) {
        float y = (float)x;
        memcpy(buf, &y, 4);
}

float read(void) {
        float r;
        memcpy(&r, buf, 4);
        return r;
}

int main(int argc, char**argv) {
        double x;
        x = strtod(argv[1], NULL);
        write(x);
        printf("%g\n", (double)read());
        return 0;
}
(cosmic-ppc64el)root at diamond:/# gcc -fno-inline -O1 -o u u.c
(cosmic-ppc64el)root at diamond:/# ./u 1e200
2.19181e+07

and unless someone can see something wrong in my C code, this looks like a
compiler bug :(

Cheers,
mwh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180904/67353b29/attachment.html>