This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix misreported errno on preadv2/pwritev2 (BZ#23579)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, samuel dot thibault at ens-lyon dot org
- Date: Wed, 24 Oct 2018 08:27:22 -0300
- Subject: Re: [PATCH] Fix misreported errno on preadv2/pwritev2 (BZ#23579)
- References: <20180829212032.32507-1-adhemerval.zanella@linaro.org> <1febaa08-ee05-1b0c-6220-be4fd76a7f7f@arm.com> <alpine.DEB.2.21.1810232125190.25657@digraph.polyomino.org.uk>
On 23/10/2018 18:37, Joseph Myers wrote:
> On Tue, 23 Oct 2018, Szabolcs Nagy wrote:
>
>> with build-many-glibcs.py in
>> logs/glibcs/i686-gnu/010-glibcs-i686-gnu-check-log.txt i see
>>
>> In file included from tst-preadvwritev2.c:26:
>> tst-preadvwritev2-common.c: In function ‘do_test_with_invalid_iov’:
>> tst-preadvwritev2-common.c:89:22: error: ‘IOV_MAX’ undeclared (first use in this function); did you mean ‘INT_MAX’?
>> struct iovec iov[IOV_MAX+1] = { 0 };
>> ^~~~~~~
>> INT_MAX
>> tst-preadvwritev2-common.c:89:22: note: each undeclared identifier is reported only once for each function it appears in
>> tst-preadvwritev2-common.c:89:18: error: unused variable ‘iov’ [-Werror=unused-variable]
>> struct iovec iov[IOV_MAX+1] = { 0 };
>> ^~~
>> cc1: all warnings being treated as errors
>> make[3]: *** [../o-iterator.mk:9: /data/glibc-build-j2/build/glibcs/i686-gnu/glibc/misc/tst-preadvwritev2.o] Error 1
>
> I guess this wasn't readily visible to people running build-many-glibcs.py
> tests because the current expected baseline is that the compilation
> testsuite doesn't have clean results on i686-gnu, ever since the C11
> threads support went in (so that this build failure appeared is only
> visible if you actually look into the log files, not if you just look at
> the summary results of build-many-glibcs.py).
>
> It would of course be good to have C11 threads support for Hurd (sharing
> as much as possible of the code to implement C11 threads on top of
> pthreads, and the associated tests for C11 threads, with those used with
> NPTL). Until we have that, maybe it would be possible to XFAIL the
> relevant conform/ tests in some Hurd sysdeps Makefile (with a comment
> referencing a bug open in Bugzilla about the lack of C11 threads support
> for Hurd)? Finding regressions with build-many-glibcs.py works much
> better if the normal expected state is no failures at all.
I agree it would be better to just XFAIL C11 threads conformance on Hurd,
I don't plan to work on it in near feature and I presume it is a low
priority issue for Hurd developers.
>
> (ia64 has also been broken with GCC mainline for over a month -
> <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01052.html>.)
>