This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Modify gcc.dg/lto/20091216-1_0.c
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Guenther <richard dot guenther at gmail dot com>, dave dot korn dot cygwin at googlemail dot com, Jack Howarth <howarth at nitro dot msbb dot uc dot edu>
- Date: Thu, 29 Apr 2010 19:48:24 +0100
- Subject: Re: [PATCH] Modify gcc.dg/lto/20091216-1_0.c
- References: <r2u571f6b511004290858pe4cafb0bhf8195efc4e9ac43f@mail.gmail.com>
On 29/04/2010 16:58, Steven Bosscher wrote:
> With that, I still have the following FAILs with LTO on Mach-O:
>
> * gcc.dg/lto/20100423-2_1.c failing because _stderr is undefined:
> Undefined symbols:^M
> "_stderr", referenced from:
> _read_error in c_lto_20100423-2_0.o
> ld: symbol(s) not found^M
Have this on Cygwin too; the testcase assumes there's an actual extern
global variable 'stderr' in libc, which is not the case on systems where
'stderr' is a macro. POSIX and n1256 only require that stdin/out/err are
'expressions of type "pointer to FILE"', so this is presumably a GLIBC-ism.
If we can't #include stdio.h, we'll just have to skip/xfail the test.
> * gcc.dg/lto/c_lto_20081201-2 because WHOPR miscompiles this
> apparently (there is no output explaining the FAIL)
This, according to what I was told in PR41529(*), is the only test that
actually makes sure LTO is really happening; not sure if that's still the
case. The execute test was failing everywhere, including Linux, for at least
some revisions recently, but looks now fixed on HEAD according to latest
gcc-testresults postings. (It'll be some days before I can get my sandbox
updated and check again.)
> * gcc.dg/lto/20081222_1.c:14:21: error: only weak aliases are
> supported in this configuration
Yep, we don't support that syntax either, we need to skip it.
> * gcc.dg/lto/20090914-1 because for some reason GCC emits an
> unrecognized assembler directive:
> /var/tmp//ccVZkECh.s:44:Unknown pseudo-op: .type
> /var/tmp//ccVZkECh.s:44:Rest of line ignored. 1st junk character valued 109 (m).
> compiler exited with status 1
Uses ELF-specific form of the .section directive in inline asm. We should
just skip it.
cheers,
DaveK
--
(*) - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41529#c10