This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp merge] Stage 2: OpenMP for the Fortran front end
On Thu, Feb 09, 2006 at 04:08:00AM -0500, Jakub Jelinek wrote:
> On Wed, Feb 08, 2006 at 04:38:24PM -0800, Steve Kargl wrote:
> > I re-installed the patch and ran "gmake check" in
> > obj4x/amd64-unknown-freebsd7.0/libgomp.
> >
> > === libgomp Summary ===
> >
> > # of expected passes 1033
> > # of unexpected failures 27
> >
> >
> > I've attached the gzipped libgomp.log file.
>
> libgomp.c/atomic-2.c fails because you have very old binutils
> and are building with -march=nocona. Guess we'll need some configure
> check for obsolete assembler that can't handle cmpxchg16b. Anyway, this has
> nothing to do with Fortran.
troutmask:kargl[232] as --version
GNU assembler 2.15 [FreeBSD] 2004-05-23
I don't keep up with all the processor naming junk. Is nocona
the same as -march=opteron?
> libgomp.fortran/omp_cond{2.f,4.F90} fail because your linker apparently
> isn't able to figure out transitive dependencies. Your libgomp.so
> ought to be linked against libpthread.so and the linker should be
> able to find that library at link time to satisfy libgomp.so's
> symbols. These two tests are the only tests that use -fno-openmp,
> so for them libgomp.spec isn't sourced in, but libgomp-dg.exp
> explicitly adds -lgomp. Guess something like:
troutmask:sgk[205] ldd amd64-unknown-freebsd7.0/libgomp/.libs/libgomp.so
amd64-unknown-freebsd7.0/libgomp/.libs/libgomp.so:
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x200945000)
libc.so.6 => /lib/libc.so.6 (0x200633000)
If libgomp requires libpthread, shouldn't we explicit add
-lgomp -lpthread in the -fno-openmp case? One other thing
that might work is to have -fno-openmp imply -pthread on
FreeBSD. I'll need to do some hunting around, but I believe
"cc -pthread" does the right thing with setting the linker.
This could be a FreeBSD local change.
> should fix this, though it will prevent us to have any
> future -fno-openmp tests which would like to use some functions
> from -lgomp.
I'd rather have you "xfail *-*-freebsd". Having a target
reduce the testing on all other platforms seems to be
counter to what we want.
> It isn't clear from the log why libgomp.fortran/omp_parse{2,4}.f90 fails
> for you, it certainly succeeds here on multiple architectures.
I'll look into this.
> libgomp.fortran/vla7.f90 is a test that worked up to a month ago or so,
> then some Fortran FE rendered it invalid and I still haven't found time to
> see what exactly is invalid and how to rewrite it into a valid Fortran
> (if possible at all). The purpose of the tests is to test behaviour of
> various parallelized functions returning variable length return values.
> Here I'd appreciate help...
I looked at this failure briefly. It appears that we need a few
dg-warning sprinkled in the code. I'll tried to help you here.
This certainly isn't a show stopper. I should be done reading the
patch later today.
--
Steve