This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Miscellaneous testsuitsuite failures under hpux 10.20
- To: dave at hiauly1 dot hia dot nrc dot ca
- Subject: Re: Miscellaneous testsuitsuite failures under hpux 10.20
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Wed, 28 Jun 2000 16:08:06 -0700
- CC: gcc-bugs at gcc dot gnu dot org
- References: <200006282122.RAA25986@hiauly1.hia.nrc.ca>
> Date: Wed, 28 Jun 2000 17:22:05 -0400 (EDT)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> Cc: gcc-bugs@gcc.gnu.org
>
> > I see no reason why a field can't be aligned to just as large a
> > boundary as any other construct.
>
> OK. It is not clear to me why both DECL_ALIGN and DECL_OFFSET_ALIGN
> are both necessary, and how they differ in function. I also have concerns
I think DECL_OFFSET_ALIGN is the actual alignment and DECL_ALIGN is
the required alignment.
> about the portability of ffs which you have used in your patch. The
That's one of the reasons the patch is not committed. Probably it
should use something like exact_log2, or supply its own ffs
equivalent.
> HP man page says it is not portable. Also, with your patch, alignments
> have to be a power of 2 and at the moment align and offset_align are
It's not clear to me what a non-power-of-two alignment would mean. Is
it really sensible to specify that something is aligned to a 3-word
boundary?
GCC already expects that many things are powers of two.
> not treated symmetrically.
We could easily fix align too. I just didn't bother.
> Wouldn't it be simpler to just the struct tree_decl definition:
>
> ...
> union {
> HOST_WIDE_INT i;
> enum built_in_function f;
> struct {unsigned int align : 24; unsigned int off_align : 8;} a;
> } u1;
>
> HOST_WIDE_INT is already long on some machines. Would just eliminating
> the bit-fields for align and offset_align be a major killer space wise
> if both fields are actually needed?
Apparently, the majority (> 50%) of space gcc uses on C++ code is used
by trees. So we don't want to make the trees any larger than necessary.
--
- Geoffrey Keating <geoffk@cygnus.com>