Patchwork Fix type of clock_t in timevar.c

login
register
mail settings
Submitter Steve Ellcey
Date Nov. 1, 2013, 5:47 p.m.
Message ID <6c2369fb-2e6d-46d9-8eb1-06de1902aac9@BAMAIL02.ba.imgtec.org>
Download mbox | patch
Permalink /patch/287879/
State New
Headers show

Comments

Steve Ellcey - Nov. 1, 2013, 5:47 p.m.
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.

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.

Tested with my canadian cross build and a native x86 linux build.

OK to checkin?

Steve Ellcey
sellcey@mips.com



2013-11-01  Steve Ellcey  <sellcey@mips.com>

	* timevar.c: Fix type of clock_t.
Mike Stump - Nov. 1, 2013, 7:43 p.m.
On Nov 1, 2013, at 10:47 AM, Steve Ellcey <sellcey@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.

> 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.
Steve Ellcey - Nov. 1, 2013, 7:56 p.m.
On Fri, 2013-11-01 at 12:43 -0700, Mike Stump wrote:
> On Nov 1, 2013, at 10:47 AM, Steve Ellcey <sellcey@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
sellcey@mips.com
Mike Stump - Nov. 1, 2013, 8:45 p.m.
On Nov 1, 2013, at 12:56 PM, Steve Ellcey <sellcey@mips.com> wrote:
>> 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).

Curious, do you have sys/time.h?  If so, that's likely the cause, as system.h does this:

# if HAVE_SYS_TIME_H
#  include <sys/time.h>
# else
#  ifdef HAVE_TIME_H
#   include <time.h>
#  endif
# endif

thus cleverly avoiding even including time.h when it exists.  I suspect TIME_WITH_SYS_TIME failed for some silly reason, though, can't guess why.  autoconf is fun when it fails.
Steve Ellcey - Nov. 1, 2013, 8:50 p.m.
On Fri, 2013-11-01 at 13:45 -0700, Mike Stump wrote:
> On Nov 1, 2013, at 12:56 PM, Steve Ellcey <sellcey@mips.com> wrote:
> >> 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).
> 
> Curious, do you have sys/time.h?  If so, that's likely the cause, as system.h does this:
> 
> # if HAVE_SYS_TIME_H
> #  include <sys/time.h>
> # else
> #  ifdef HAVE_TIME_H
> #   include <time.h>
> #  endif
> # endif
> 
> thus cleverly avoiding even including time.h when it exists.  I suspect
> TIME_WITH_SYS_TIME failed for some silly reason, though, can't guess why.
> autoconf is fun when it fails.

Yes, mingw does have sys/time.h, but their sys/time.h includes <time.h>
so it should work.  And now when I try to reproduce the problem it seems
to work.  I am getting HAVE_CLOCK_T defined in auto-build.h and
auto-host.h.

Steve Ellcey
sellcey@mips.com
Mike Stump - Nov. 1, 2013, 9:44 p.m.
On Nov 1, 2013, at 1:50 PM, Steve Ellcey <sellcey@mips.com> wrote:
> Yes, mingw does have sys/time.h, but their sys/time.h includes <time.h>
> so it should work.  And now when I try to reproduce the problem it seems
> to work.

:-)  Don't worry, when I was in getting my degree, I helped out in the lab, some bugs know it's me and run away; this is normal.

Patch

diff --git a/gcc/timevar.c b/gcc/timevar.c
index 23b7118..b66f94a 100644
--- a/gcc/timevar.c
+++ b/gcc/timevar.c
@@ -23,7 +23,7 @@  along with GCC; see the file COPYING3.  If not see
 #include "timevar.h"
 
 #ifndef HAVE_CLOCK_T
-typedef int clock_t;
+typedef long clock_t;
 #endif
 
 #ifndef HAVE_STRUCT_TMS