On Fri, 6 Jul 2001, Peter Jeremy wrote:

> On 2001-Jul-05 20:31:43 -0700, Matthew Jacob <[EMAIL PROTECTED]> wrote:
> >Perhaps what we really need- and this is really a toolchain issues- is a
> >compiler that is just as stringent on i386 as on alpha?
> IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
> same compiler).

True. I didn't quite put it correctly. It's true that the compilers are
the same- but they do have different code generators, and they really do
have different levels of acceptance for errors that don't seem to be
type related.

>  IMHO, the problem splits into two categories:
> Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
> and the i386. 

Yes.  This tends to be caught by the alpha compiler but the i386.
It'd be nice if there were a -Wpun. For example:


func(char *p)
        int j = (int) p;
        return j + 1;

On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
NetBSD/alpha (same compiler, really), this produces:

x.c: In function `func':
x.c:4: warning: cast from pointer to integer of different size

It'd be *really* nice if we could add a flag where such errors could be
checked for and emitted for an i386 build.

> Secondly, there are cases where different architectures
> map foo_t onto different primitive types.  Both these problems are
> very difficult to solve using a lint-like tool running on only one
> architecture.
> As examples of the latter, a quick diff of
> /sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
>                 i386 type     Alpha type
> clock_t               unsigned long   int

Both should be u_int32_t until we decide Unix will last past 2038(?) in
which case they'll both be uint64...

> ptrdiff_t     int             long
> size_t                unsigned int    unsigned long
> ssize_t               int             long
> off_t         __int64_t       long
> *physaddr     { int r[1]; }   { long r[1]; }
> label_t               { int [6]; }    { long [10]; }
> vm_offset_t   unsigned int    unsigned long
> vm_ooffset_t  __int64_t       long
> vm_pindex_t   unsigned int    unsigned long
> vm_size_t     unsigned int    unsigned long
> register_t    __int32_t       __int64_t
> u_register_t  __uint32_t      __uint64_t
> intfptr_t     int             long
> uintfptr_t    unsigned int    unsigned long

I'm a little out of my depth about the right thing here- my
heavy toolchain experience is >= 10 years ago. I wish Bruce and/or David
could help sort this out.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to