This is the mail archive of the
mailing list for the GCC project.
Re: Building gcc with broken gfortran
On Fri, Jan 11, 2019 at 7:43 PM NightStrike <email@example.com> wrote:
> On Fri, Jan 11, 2019 at 11:52 AM Steve Kargl
> <firstname.lastname@example.org> wrote:
> > > > ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,fortran
> > > > --enable-bootstrap --disable-nls
> > >
> > > Does that work on RHEL or Cent 6? I don't see much different in what
> > > I'm doing, other than wanting the faster clock_gettime.
> > I use neither RHEL nor Cent 6. May be that's you're problem. :)
> > Have you tried the above exactly as I have typed it qout? Your
> > configure line starts with "../configure" suggesting that
> > you are building within the source code directory. Isn't
> > that taboo? What happens if you remove --enable-libstdcxx-time=rt?
> Configuring (slightly differently) with --enable-languages=fortran
> --disable-nls --disable-multilib
> I guess I have some more combinations to test.......
> > I don't understand what you mean by "wanting the faster clock_gettime".
> > gfortran's system_clock() will use clock_gettime if configure finds
> > that it is available on your system.
> > % nm objx/x86_64-unknown-freebsd13.0/libgfortran/system_clock.o
> > 0000000000000000 T _gfortran_system_clock_4
> > 0000000000000000 T _gfortran_system_clock_8
> > U clock_gettime
> > program foo
> > implicit none
> > integer(8) count1, count2, rate, cmax
> > call system_clock(count1, rate, cmax)
> > print '(A,I0)', 'count = ', count1
> > print '(A,I0)', ' rate = ', rate
> > print '(A,I0)', ' cmax = ', cmax
> > call system("sleep 1") ! sleep for 1 second + plus system
> > call system_clock(count2)
> > print '(A,I0)', ' count = ', count2
> > print '(A,F8.4)', 'elaspe = ', real(count2 - count1, 8) / rate
> > end program foo
> > % gfcx -o z d.f90 && ./z
> > count = 2588092417916290
> > rate = 1000000000
> > cmax = 9223372036854775807
> > count = 2588093482115892
> > elaspe = 1.0642
> I need this for C++, so that std::chrono::now() takes 200ns instead of
> 2000ns (yes, it matters there). On RHEL/Cent 6, the included version
> of glibc puts the faster VDSO method of getting time into librt, so
> you need to explicitly link with -lrt to use it. In later versions of
> glibc, it's part of libc, and so this isn't required. Jon told me I
> could do away with that now, but I haven't tested it yet. I hope he's
> right, since I think you've proven that that might be part of my
> overall problem.
> Anyway, I just built 8.2 with the options listed above. I'm now going
> to add back in just the --enable-libstdcxx-time=rt option to see if
> things break again. If so, we've got a big clue to our culprit.
libgfortran does a configure test to see if clock_gettime is available in
librt, if so it does some weak reference trickery to use clock_gettime if
it's available at runtime, else it falls back to gettimeofday.
But I have a hard time seeing how that would be related to
--enable-libstdcxx-time=rt since libgfortran doesn't link to libstdc++, and
further, the __cpu_model usage is in the implementation of the matmul
intrinsic, not in anything to do with timing functions.