From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16456 invoked by alias); 12 Dec 2008 19:29:09 -0000 Received: (qmail 16148 invoked by alias); 12 Dec 2008 19:27:47 -0000 Date: Fri, 12 Dec 2008 19:29:00 -0000 Message-ID: <20081212192747.16147.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90" In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-12/txt/msg01359.txt.bz2 ------- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12 19:27 ------- Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90" > My long term guidance would be to engineer gcc to use its copy of the libgcc_s > dylib and link against it. This would mean that the newly installed libgcc_s > should be found first, over /usr/lib, and that development and support mirror > linux, in all the usual ways. That's certainly reasonable. However, linux style TLS support needs help from the assembler, linker and dynamic loader. So, unless this is going to happen, the best that can be achieved is that provided by the emulation layer. Tracking linux might be straight forward if the kernel supported ELF executables. Then, x86 linux tools would work essentially as is. However, I'm sure there would be issues with syscalls, etc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677