From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: x86_64 gcc test failures at the end of gcc-7 stage 1
Date: Sat, 12 Nov 2016 19:25:23 -0500 [thread overview]
Message-ID: <20161113002523.GP1555@brightrain.aerifal.cx> (raw)
In-Reply-To: <20161112174350.GQ5749@port70.net>
On Sat, Nov 12, 2016 at 06:43:50PM +0100, Szabolcs Nagy wrote:
> my analysis of gcc test failures i've seen on x86_64-linux-musl
> (gcc, g++, gfortran, libstdc++):
>
> unwind/throw across signal handler (sigreturn unwind info is missing in musl)
> FAIL: gcc.dg/cleanup-10.c execution test
> FAIL: gcc.dg/cleanup-11.c execution test
> FAIL: gcc.dg/cleanup-8.c execution test
> FAIL: gcc.dg/cleanup-9.c execution test
> FAIL: g++.dg/eh/sighandle.C -std=gnu++11 execution test
> FAIL: g++.dg/eh/sighandle.C -std=gnu++14 execution test
> FAIL: g++.dg/eh/sighandle.C -std=gnu++98 execution test
> FAIL: g++.dg/ext/cleanup-10.C -std=gnu++11 execution test
> FAIL: g++.dg/ext/cleanup-10.C -std=gnu++14 execution test
> FAIL: g++.dg/ext/cleanup-10.C -std=gnu++98 execution test
> FAIL: g++.dg/ext/cleanup-11.C -std=gnu++11 execution test
> FAIL: g++.dg/ext/cleanup-11.C -std=gnu++14 execution test
> FAIL: g++.dg/ext/cleanup-11.C -std=gnu++98 execution test
> FAIL: g++.dg/ext/cleanup-8.C -std=gnu++11 execution test
> FAIL: g++.dg/ext/cleanup-8.C -std=gnu++14 execution test
> FAIL: g++.dg/ext/cleanup-8.C -std=gnu++98 execution test
> FAIL: g++.dg/ext/cleanup-9.C -std=gnu++11 execution test
> FAIL: g++.dg/ext/cleanup-9.C -std=gnu++14 execution test
> FAIL: g++.dg/ext/cleanup-9.C -std=gnu++98 execution test
> FAIL: g++.dg/ext/sync-4.C -std=gnu++11 execution test
> FAIL: g++.dg/ext/sync-4.C -std=gnu++14 execution test
> FAIL: g++.dg/ext/sync-4.C -std=gnu++98 execution test
I think these are not supported/intended to work.
> throw from libc callback (pthread_once unwind info is missing)
> FAIL: 30_threads/async/forced_unwind.cc execution test
> FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
This failure is expected/intentional. Even if there were unwind info,
it would not be safe to jump out and leave the state of the once
object inconsistent.
> missing ucontext api (makecontext, swapcontext)
> FAIL: gcc.dg/split-5.c (test for excess errors)
> UNRESOLVED: gcc.dg/split-5.c compilation failed to produce executable
>
> missing fortify api (__memcpy_chk)
> FAIL: gcc.dg/strlenopt-2f.c (test for excess errors)
> UNRESOLVED: gcc.dg/strlenopt-2f.c compilation failed to produce executable
>
> no short wchar support (__WCHAR_TYPE__ is ignored)
> FAIL: gcc.dg/utf-array-short-wchar.c (test for errors, line 39)
> FAIL: gcc.dg/utf-array-short-wchar.c (test for errors, line 41)
> FAIL: gcc.dg/utf-array-short-wchar.c (test for excess errors)
Also intentional/a feature. :-)
> math_errhandling & MATH_ERRNO is not supported
> FAIL: gcc.dg/torture/pr68264.c -O0 execution test
> FAIL: gcc.dg/torture/pr68264.c -O1 execution test
> FAIL: gcc.dg/torture/pr68264.c -O2 execution test
> FAIL: gcc.dg/torture/pr68264.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
> FAIL: gcc.dg/torture/pr68264.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
> FAIL: gcc.dg/torture/pr68264.c -O3 -g execution test
> FAIL: gcc.dg/torture/pr68264.c -Os execution test
Likewise.
> testcase redefines __inline
> FAIL: gcc.target/i386/avx-1.c (test for excess errors)
> FAIL: gcc.target/i386/avx-2.c (test for excess errors)
> FAIL: gcc.target/i386/sse-13.c (test for excess errors)
> FAIL: gcc.target/i386/sse-14.c (test for excess errors)
> FAIL: gcc.target/i386/sse-22.c (test for excess errors)
> FAIL: gcc.target/i386/sse-22a.c (test for excess errors)
> FAIL: gcc.target/i386/sse-23.c (test for excess errors)
> FAIL: gcc.target/i386/sse-24.c (test for excess errors)
> FAIL: gcc.target/i386/sse-25.c (test for excess errors)
Would refraining from defining it when __GNUC__ is defined fix these
tests? We could consider that. Or we could just use a different name
for it internally, e.g.:
#if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
#define ___inline inline
#elif defined(__GNUC__)
#define ___inline __inline
#else
#define ___inline
#endif
> math/complex precision test failures
> FAIL: gfortran.dg/bessel_6.f90 -O0 execution test
> FAIL: gfortran.dg/bessel_6.f90 -O1 execution test
> FAIL: gfortran.dg/bessel_6.f90 -O2 execution test
> FAIL: gfortran.dg/bessel_6.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> FAIL: gfortran.dg/bessel_6.f90 -O3 -g execution test
> FAIL: gfortran.dg/bessel_6.f90 -Os execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -O0 execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -O1 execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -O2 execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -g execution test
> FAIL: gfortran.dg/complex_intrinsic_5.f90 -Os execution test
> FAIL: gfortran.dg/erf_3.F90 -O0 execution test
> FAIL: gfortran.dg/erf_3.F90 -O1 execution test
> FAIL: gfortran.dg/erf_3.F90 -O2 execution test
> FAIL: gfortran.dg/erf_3.F90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> FAIL: gfortran.dg/erf_3.F90 -O3 -g execution test
> FAIL: gfortran.dg/erf_3.F90 -Os execution test
> FAIL: 26_numerics/complex/13450.cc execution test
To be fixed eventually, I guess?
> gnu vs generic c++ locale abi diff
> FAIL: libstdc++-abi/abi_check
Probably a non-issue, and almost certainly doesn't make sense to
change (break) at this point anyway.
> FILE is incomplete
> FAIL: 27_io/headers/cstdio/types_std.cc (test for excess errors)
Intentional.
> gcc plugins fail with cross libc testing (when running tests on glibc host)
> FAIL: gcc.dg/plugin/*
> FAIL: g++.dg/plugin/*
>
> known gcc-trunk failures
> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
> FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)
> FAIL: gfortran.dg/graphite/pr68279.f90 -O (test for excess errors)
> FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\\\[-10, 9\\\\]" 1
>
> unknown:
> FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4
> FAIL: gfortran.dg/coarray/event_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic execution test
Not sure about any of these.
Rich
prev parent reply other threads:[~2016-11-13 0:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-12 17:43 Szabolcs Nagy
2016-11-13 0:25 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161113002523.GP1555@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).