gcc: Document new test failures with Glibc-2.38

Well, the analyzer failures are introduced by literally *my* Glibc
change [1] and I'll sort them out for GCC 14...

And the ASAN failures seem caused by the introduction of
__isoc23_strtol (the libsanitizer does not know to intercept it).  I'll
test with LLVM once I reach it in BLFS (LLVM is the upstream of
libsanitizer) and make a bug report.

limits-exprparen.c also fails to me, it needs "ulimit -s 65536" instead
of "ulimit -s 32768" in my build but maybe it's caused by my custom
*FLAGS.

[1]:https://sourceware.org/git/?p=glibc.git;a=commit;h=71d9e0fe766a
This commit is contained in:
Xi Ruoyao 2023-08-02 14:02:08 +08:00
parent 7a8fcc3918
commit f40b2e7be5
No known key found for this signature in database
GPG Key ID: ACAAD20E19E710E3

View File

@ -184,6 +184,16 @@ su tester -c "PATH=$PATH make -k check"</userinput></screen>
<filename class='directory'>vect</filename> directory are known to fail <filename class='directory'>vect</filename> directory are known to fail
if the hardware does not support AVX.</para> if the hardware does not support AVX.</para>
<para>
With Glibc-2.38, the analyzer tests named
<filename>data-model-4.c</filename> and
<filename>conftest-1.c</filename> are known to fail.
In the asan tests, the subtest named
<filename>AddressSanitizer_StrtolOOBTest</filename> in the test
<filename>asan_test.C</filename> and the test named
<filename>interception-malloc-test-1.C</filename> are known to fail.
</para>
<para>A few unexpected failures cannot always be avoided. The GCC developers <para>A few unexpected failures cannot always be avoided. The GCC developers
are usually aware of these issues, but have not resolved them yet. are usually aware of these issues, but have not resolved them yet.
Unless the test results are vastly different from those at the above URL, Unless the test results are vastly different from those at the above URL,