On Fri, 2013-11-01 at 12:43 -0700, Mike Stump wrote: > On Nov 1, 2013, at 10:47 AM, Steve Ellcey <sell...@mips.com> wrote: > > While working on a canadian cross build I ran into a problem with the > > type of clock_t. If HAVE_CLOCK_T is not defined > > > timevar.c defines it to be int. I think the type should be long. I am > > using the mingw > > compilers on linux in my canadian cross build and HAVE_CLOCK_T is not > > getting set but when building I get a conflict between the definition > > of clock_t in /usr/i586-mingw32msvc/include/time.h (long) and the > > definition in timevar.c. > > You should report a bug to them and have them define clock_t.
They are defining clock_t, but for some reason the GCC configure is not seeing it (perhaps because of what header files get included). > > Since mingw and linux and glibc and newlib all seem to agree on long > > I would like to change timevar.c to agree with them. > > Seems reasonable to me, though newlib and macosx use unsigned long. glibc > remains at long, due to binary compatibility. Ah, I confused _CLOCK_T_ (unsigned long) with __CLOCK_T_TYPE (long) in newlib. clock_t is defined as _CLOCK_T_ in newlib, not __CLOCK_T_TYPE. Steve Ellcey sell...@mips.com
