On Fri, Nov 01, 2024 at 02:01:18PM -0400, John David Anglin wrote:
> This breaks build on hppa64-hp-hpux11.11. This target has clock_gettime
> but it doesn't have CLOCK_MONOTONIC. It has CLOCK_REALTIME. I modified
> timevar.cc as follows to restore build.
Alternative would be to check for CLOCK
This breaks build on hppa64-hp-hpux11.11. This target has clock_gettime
but it doesn't have CLOCK_MONOTONIC. It has CLOCK_REALTIME. I modified
timevar.cc as follows to restore build.
Dave
---
diff --git a/gcc/timevar.cc b/gcc/timevar.cc
index e12775e6ff3..412d9b62a8f 100644
--- a/gcc/timevar.c
> I'm getting a build failure:
>
> timevar.cc:163: undefined reference to `clock_gettime'
>
> Our frozen build tools are intended to produce binaries that work
> "everywhere", so they're a few years old, but apparently something didn't
> configure correctly.
>
> I see that libbacktrace configure
On 30/10/2024 16:06, Andi Kleen wrote:
On Wed, Oct 23, 2024 at 02:56:51PM +0200, Richard Biener wrote:
On Wed, Oct 9, 2024 at 6:18 PM Andi Kleen wrote:
From: Andi Kleen
Retrieving sys/user time in timevars is quite expensive because it
always needs a system call. Only getting the wall time
On Wed, Oct 23, 2024 at 02:56:51PM +0200, Richard Biener wrote:
> On Wed, Oct 9, 2024 at 6:18 PM Andi Kleen wrote:
> >
> > From: Andi Kleen
> >
> > Retrieving sys/user time in timevars is quite expensive because it
> > always needs a system call. Only getting the wall time is much
> > cheaper bec
On Wed, Oct 9, 2024 at 6:18 PM Andi Kleen wrote:
>
> From: Andi Kleen
>
> Retrieving sys/user time in timevars is quite expensive because it
> always needs a system call. Only getting the wall time is much
> cheaper because operating systems have optimized paths for this.
>
> The sys time isn't t
