This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building gcc with broken gfortran


On Fri, Jan 11, 2019 at 7:43 PM NightStrike <nightstrike@gmail.com> wrote:

> On Fri, Jan 11, 2019 at 11:52 AM Steve Kargl
> <sgk@troutmask.apl.washington.edu> 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
> ..............worked.
>
> 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.

-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]