Re: [PATCH v8 2/2] Y2038: make __tz_convert compatible with 64-bit-time

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Joseph,

On Wed, 26 Sep 2018 16:14:06 +0000, Joseph Myers
<joseph@codesourcery.com> wrote :

> On Wed, 26 Sep 2018, Albert ARIBAUD (3ADEV) wrote:
> 
> > Now that __time_64_t exists, we can switch internal function
> > __tz_convert from 32-bit to 64-bit time. This involves switching
> > some other internal functions and turning some implementations
> > which use these into wrappers between public 32-bit and internal
> > 64-bit time.  
> 
> You're missing the information about what platforms this patch was tested 
> on with the full glibc testsuite.  That's critical information for such a 
> patch submission, which needs testing on both 32-bit and 64-bit platforms.  
> (Later patches supporting using new syscalls will need testing on 
> additional configurations, including building with old kernel headers; 
> building with kernel headers with the new syscalls but running on a kernel 
> without them; and building with new kernel headers and running on a kernel 
> with the new syscalls.)

I've started with the simplest case for me, a native x86_64 test on
a Xubuntu 18.04 machine with gcc 7.3.0. This is how I did it:

$ cd /home/3adev/glibc/build
$ /home/3dev/glibc/src/configure --prefix /home/3adev/glibc/local
$ make -j3
$ make -j3 check

Running this with /home/3dev/glibc/{build,local} empty,
and /home/3dev/glibc/src being a checkout of tag glibc-2.28, that is,
without any patches of mine.

I end up with

> [...]
> Summary of test results:                                       
>     132 FAIL
>    5788 PASS
>      11 UNSUPPORTED
>      17 XFAIL
>       2 XPASS
> Makefile:345: recipe for target 'tests' failed
> make[1]: *** [tests] Error 1
> make[1] : on quitte le répertoire « /home/3adev/glibc/src »
> Makefile:9: recipe for target 'check' failed
> make: *** [check] Error 2

Is it normal that the make check fail with a non-zero number of FAIL and
XFAIL?

If it is not a normal result, then what could possibly cause it
considering I am building the official glibc 2.28?

Is it is a normal result (i.e. this release of glibc is known to FAIL
and XFAIL this way for x86_64), then where can I find the expected FAIL
and XFAIL details for a given architecture and a given release of glibc?

Cordialement,
Albert ARIBAUD
3ADEV