Automatic merge of trunk into multilib

This commit is contained in:
Thomas Trepl 2024-02-19 00:30:10 +01:00
commit 44b216e805
2 changed files with 35 additions and 53 deletions

View File

@ -193,48 +193,30 @@ su tester -c "PATH=$PATH make -k check"</userinput></screen>
url="&test-results;"/> and
<ulink url="https://gcc.gnu.org/ml/gcc-testresults/"/>.</para>
<para><!--Two tests named <filename>pr104610.c</filename> and
<filename>pr69482-1.c</filename> are known to fail because the test
files does not account for the
<parameter>- -enable-default-ssp</parameter> option.-->
<!-- https://gcc.gnu.org/PR106375 and https://gcc.gnu.org/PR109353 -->
Eight gcc tests (out of over 185,000), data-model-4.c, pr56837.c,
and six "analyzer" tests are known to fail.
<para>
Eight gcc tests (out of over 185,000):
<!-- https://gcc.gnu.org/PR106375 --><filename>pr56837.c</filename>
and seven tests in the <filename class='directory'>analyzer</filename>
directory are known to fail.
One libstdc++ test (out of over 15000), copy.cc, is known to fail.
<!-- https://gcc.gnu.org/PR109353 -->
One libstdc++ test (out of over 15000), <filename>copy.cc</filename>, is
known to fail.
For g++, 21 tests (out of approximately 250,000), 14 "AddressSanitizer*"
tests and 7 interception-malloc-test-1.C tests, are known to fail.
For g++, 21 tests (out of approximately 250,000): 14
<quote>AddressSanitizer*</quote>
tests and 7 <filename>interception-malloc-test-1.C</filename> tests, are
known to fail.
Additionally, several tests in the
<filename class='directory'>vect</filename> directory are known to fail
if the hardware does not support AVX.</para>
<!--
<para>
With Glibc-2.39, the gcc analyzer tests named
<filename>data-model-4.c</filename> and
<filename>conftest-1.c</filename>
are known to fail.
In the asan tests, several tests in <filename>asan_test.C</filename>
are known to fail.
The test named <filename>interception-malloc-test-1.C</filename>
is known to fail.
</para>
-->
<para>A few unexpected failures cannot always be avoided. The GCC developers
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,
it is safe to continue.</para>
<!--note><para>
On some combinations of kernel configuration and AMD processors
there may be more than 1100 failures in the gcc.target/i386/mpx
tests (which are designed to test the MPX option on recent
Intel processors). These can safely be ignored on AMD
processors. These tests will also fail on Intel processors if MPX support
is not enabled in the kernel even though it is present on the CPU.
</para></note-->
<para>Install the package:</para>
<screen><userinput remap="install">make install</userinput></screen>

View File

@ -170,34 +170,34 @@ esac</userinput></screen>
is known to fail in the LFS chroot environment.</para>
</listitem>
<listitem>
<para>Three <emphasis>nptl/tst-thread-affinity*</emphasis>
tests are known to fail.</para>
</listitem>
<!-- Did not fail with glibc-2.38
<listitem>
<para><emphasis>misc/tst-ttyname</emphasis>
is known to fail in the LFS chroot environment.</para>
</listitem>
-->
<!-- https://sourceware.org/pipermail/libc-alpha/2022-August/141567.html -->
<listitem>
<para>The <emphasis>stdlib/tst-arc4random-thread</emphasis>
test is known to fail if the host kernel is relatively old.</para>
</listitem>
<listitem>
<para>Some tests, for example
<emphasis>nss/tst-nss-files-hosts-multi</emphasis>,
are known to fail on relatively slow systems due to an internal
timeout.</para>
<emphasis>nss/tst-nss-files-hosts-multi</emphasis> and
<emphasis>nptl/tst-thread-affinity*</emphasis>
are known to fail due to a timeout (especially when the system is
relatively slow and/or running the test suite with multiple
parallel make jobs). These tests can be identified with:</para>
<!-- TODO: Using nodump for freeze. Change it to role="test" after
12.1 release so jhalfs can list these in the log. -->
<screen role="nodump"><userinput>grep "Timed out" -l $(find -name \*.out)</userinput></screen>
<para>It's possible to re-run a single test with enlarged timeout
with
<command>TIMEOUTFACTOR=<replaceable>&lt;factor&gt;</replaceable>
make test t=<replaceable>&lt;test name&gt;</replaceable></command>.
For example, <command>TIMEOUTFACTOR=10 make test
t=nss/tst-nss-files-hosts-multi</command> will re-run
<emphasis>nss/tst-nss-files-hosts-multi</emphasis> with ten times
the original timeout.</para>
</listitem>
<listitem>
<para>Additionally, some tests may fail with a relatively old CPU
model or host kernel version.</para>
model (for example
<emphasis>elf/tst-cpu-features-cpuinfo</emphasis>) or host kernel
version (for example
<emphasis>stdlib/tst-arc4random-thread</emphasis>).</para>
</listitem>
</itemizedlist>