[PATCH 00/10] Update tests for GCC 4.9.3 and 5.4.1

[H.J. Lu]

On Tue, Dec 17, 2024 at 3:26 AM Sam James <sam@gentoo.org> wrote:
>
> Joseph Myers <josmyers@redhat.com> writes:
>
> > On Sat, 14 Dec 2024, Sam James wrote:
> >
> >> If you have time, could you look at Clang next? If not, I'll put it on
> >> my list. Thanks.
> >
> > Doesn't Adhemerval have a patch series there (azanella/clang branch)?
>
> I'd known peripherally about it, but hadn't looked in a while and hadn't
> realised it progressed to the point of the testsuite either.
>
> > (That also includes patches for building glibc with Clang.  In any patch
> > submissions, I'd encourage a clear division between (a) installed header
> > fixes for a wider range of compilers, (b) testcase fixes for a wider range
> > of compilers, and (c) changes for building glibc itself with a wider range
> > of compilers.  Since for (c) there's much more scope for considering
> > case-by-case whether each individual change is desirable or whether we
> > should say that a particular feature or bug fix is needed for any compiler
> > building glibc.)
>
> Yeah, agreed. So far, all the patches have been (b) from H.J. I expect
> that we'll end up having a mix of (a) and (c) too for Clang
> specifically.
>
> With regard to azanella's branch: is there a reason they've not been
> sent out, at least the test changes? I suppose the test side wasn't too
> relevant until the rest landed, until now (TEST_CC, TEST_CXX
> support). azanella?

I have patches to build glibc tests with Clang, except for

clang tst-rfc3484.c -c -std=gnu11 -fgnu89-inline  -O2 -g -Wall
-Wwrite-strings -Wundef -Wimplicit-fallthrough -Werror
-fmerge-all-constants -frounding-math -fstack-protector-all
-fno-common -U_FORTIFY_SOURCE -Wstrict-prototypes
-Wold-style-definition -fmath-errno    -fPIE   -fcf-protection
-Wno-gnu-folding-constant -Wno-unknown-attributes -Wno-unknown-pragmas
-Wno-unknown-warning-option -Wno-format     -I../include
-I/export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/nss
 -I/export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux
 -I../sysdeps/unix/sysv/linux/x86_64/64
-I../sysdeps/unix/sysv/linux/x86_64/include
-I../sysdeps/unix/sysv/linux/x86_64
-I../sysdeps/unix/sysv/linux/x86/include
-I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
-I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
-I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
-I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu
-I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64
-I../sysdeps/x86/include -I../sysdeps/x86
-I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include
-I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.
-D_LIBC_REENTRANT -include
/export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/libc-modules.h
-DMODULE_NAME=testsuite_internal -include ../include/libc-symbols.h
-DPIC     -DTOP_NAMESPACE=glibc -o
/export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/nss/tst-rfc3484.o
-MD -MP -MF /export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/nss/tst-rfc3484.o.dt
-MT /export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/nss/tst-rfc3484.o
In file included from tst-rfc3484.c:60:
./getaddrinfo.c:1884:11: error: variable 'endp' is used uninitialized
whenever '||' condition is true [-Werror,-Wsometimes-uninitialized]
 1884 |       && (cp == NULL
      |           ^~~~~~~~~~
./getaddrinfo.c:1887:11: note: uninitialized use occurs here
 1887 |       && *endp == '\0'
      |           ^~~~
./getaddrinfo.c:1884:11: note: remove the '||' if its condition is always false
 1884 |       && (cp == NULL
      |           ^~~~~~~~~~
 1885 |           || (bits = strtoul (cp, &endp, 10)) != ULONG_MAX
      |           ~~
./getaddrinfo.c:1875:13: note: initialize the variable 'endp' to
silence this warning
 1875 |   char *endp;
      |             ^
      |              = NULL
./getaddrinfo.c:2045:13: error: variable 'endp' is used uninitialized
whenever '||' condition is true [-Werror,-Wsometimes-uninitialized]
 2045 |                       && (cp == NULL
      |                           ^~~~~~~~~~
./getaddrinfo.c:2048:13: note: uninitialized use occurs here
 2048 |                       && *endp == '\0'
      |                           ^~~~
./getaddrinfo.c:2045:13: note: remove the '||' if its condition is always false
 2045 |                       && (cp == NULL
      |                           ^~~~~~~~~~
 2046 |                           || (bits = strtoul (cp, &endp, 10))
!= ULONG_MAX
      |                           ~~
./getaddrinfo.c:2034:18: note: initialize the variable 'endp' to
silence this warning
 2034 |               char *endp;
      |                         ^
      |                          = NULL
2 errors generated.
make[2]: *** [../o-iterator.mk:9:
/export/build/gnu/tools-build/glibc-cet-gitlab-clang/build-x86_64-linux/nss/tst-rfc3484.o]
Error 1

This is a real glibc bug and I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=32465

While doing this, I found out that it would be extremely difficult to
build and test the full glibc with Clang 19 because

1. Clang 19 has its own copies of <float.h> and <tgmath.h>.  It doesn't
use the ones from glibc.  But libm must be built from glibc's <float.h>
and <tgmath.h>.  Also the type generic libm tests must be built with
glibc's <float.h> and <tgmath.h>.
2. Unlike GCC, libmvec interface is hard-coded in Clang.  Clang doesn't
support the new libmvec funtions added to glibc later.

> I assume they're, in some form, not ready or incomplete, but I'm not
> sure if that means the existing patches have some known defects, or
> simply that there's more to be done.

-- 
H.J.