[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] 64-bit cleaning [PATCH]
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] 64-bit cleaning [PATCH] |
Date: |
Mon, 8 Sep 2003 09:17:33 -0700 (PDT) |
> From: John Goerzen <address@hidden>
> On Mon, Sep 08, 2003 at 03:30:03PM +0900, Stephen J. Turnbull wrote:
> > >>>>> "John" == John Goerzen <address@hidden> writes:
> > John> (-Wall is very useful on gcc)
> > Either -Wstrict-aliasing or -fno-strict-aliasing is a really good
> > idea. (AFAIK gcc 3.x doesn't warn on aliasing with -Wall, but it
> > really should.) Arch in particular is known to have a few places with
> > aliasing issues.
> My understanding of those options (I assume you meant -fstrict-aliasing)
is
> somewhat limited, but from the manpage, it indicates:
> vates optimizations based on the type of expressions. In
particu-
> lar, an object of one type is assumed never to reside at the
same
> address as an object of a different type, unless the types are
> almost the same. For example, an "unsigned int" can alias an
> "int", but not a "void*" or a "double". A character type may
alias
> any other type.
> Given that hackerlab does exactly that all over the place, it would
require
> conversion of a lot of code to use unions instead of void *.
> I'm not opposed to that, and personally think it a good idea, but I'd
rather
> not do it until Tom indicates he'd accept such changes. Tom?
The stuff in Rx and VU has some data structures that contain a `void
*' which can contain arbitrary, application-provided data. Some other
parts of Rx use this to pass a long value (formerly, an int -- but
this changed killed off a bunch of dumb gcc warnings). In VU i've
introduced "double casts" where an int is stored in one of these
rocks.
A change to use a union there raises three issues:
1) It's an interface change to what I'd prefer to keep as
a stable interface. This is a weak preference, though,
because the interfaces in question are still fairly
obscure -- I don't _think_ that many 3rd party systems
are relying on them.
2) What's going to go in this union? The only answer
I can see is to cover the basic scalar types that
will fit. But that's a minor annoyance because instead
of just casting to and from (void *), proper client
programs will have to do some per-machine configuration
to pick which is the appropriate union member to use.
I don't know what the heck a client will do if it wants
to store a tiny structure or union. Ick.
3) Using a union here is ugly.
The other issues, I suppose, are the array headers in ar.c and, though
it isn't built by default, problably the malloc in the piw*
directories. I dunno -- it looks like C to me.
So, I'm not terribly enthusiastic about such changes -- but I'd be
willing to look at them and reconsider. Perhaps if you show just
a few samples of the changes you have in mind so I can get a
representative feel for their implications without your having to do
all the work up-front.
-t
- Re: [Gnu-arch-users] 64-bit cleaning [PATCH], (continued)
Re: [Gnu-arch-users] 64-bit cleaning [PATCH], Momchil Velikov, 2003/09/06
Re: [Gnu-arch-users] 64-bit cleaning [PATCH], Stephen J. Turnbull, 2003/09/08
Re: [Gnu-arch-users] 64-bit cleaning [PATCH], Stephen J. Turnbull, 2003/09/09
Re: [Gnu-arch-users] 64-bit cleaning [PATCH], Tom Lord, 2003/09/08