Re: unable to detect exception model

[Richard Guenther <rguenther at suse dot de>]

On Mon, 26 Jun 2006, Eric Botcazou wrote:

> > Reverting your patch makes it go away too.  I'll try and look into it
> > tomorrow.
> 
> tree
> build_string (int len, const char *str)
> {
>   tree s;
>   size_t length;
>   
>   length = len + sizeof (struct tree_string);
> 
>   s = ggc_alloc_tree (length);
> 
> Breakpoint 5, build_string (len=34,
>     str=0x1048e58 "No space for profiling buffer(s)\n")
>     at /home/eric/svn/gcc/gcc/tree.c:1124
> 1124      length = len + sizeof (struct tree_string);
> (gdb) next
> 1131      s = ggc_alloc_tree (length);
> (gdb) p length
> $1 = 58
> (gdb) next
> 1133      memset (s, 0, sizeof (struct tree_common));
> (gdb) p s
> $2 = 0xff3803fc
> 
> 's' should be 8-byte aligned because it's a "tree".

The way it works is that ggc_alloc_stat is asked for 58 bytes, which
if being a correct C object size, has alignof (object) == 2.  Now, with

struct tree_string GTY(())
{
  struct tree_common common;
  int length;
  char str[1];
};

it is unfortunate that we compute the allocation size by doing magic
arithmetic instead of asking for  sizeof (struct 
tree_string_with_length_FOO)  (maybe one can do this with some VLA 
type?!).

At least I know what's going on, and given stage3 and yadayada it might
be best to revert the non-bugfixing parts of the patch.  Or adjust
all ggc_alloc callers to request properly aligned storage...  e.g. for
this particular case

Index: tree.c
===================================================================
--- tree.c      (revision 115006)
+++ tree.c      (working copy)
@@ -1121,7 +1121,8 @@ build_string (int len, const char *str)
   tree s;
   size_t length;
   
-  length = len + sizeof (struct tree_string);
+  length = (len + sizeof (struct tree_string)
+           + __alignof__ (struct tree_string)) & ~__alignof__ (struct 
tree_string);
 
 #ifdef GATHER_STATISTICS
   tree_node_counts[(int) c_kind]++;

but with this things going on, the whole reasoning why the patch is
correct falls apart (if we declare doing so correct).

Thanks for tracking this down (and I wonder why ia64 bootstrap succeeded
with trapping misaligned),

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs