This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Miscellaneous testsuitsuite failures under hpux 10.20


> 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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]