Re: pch bug fix

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Dec 31, 2013 at 10:39:58PM -0800, Mike Stump wrote:
> In testing for wide-int, we discovered that someone seems to have blown
> pch.  The problem is that the optabs field is not a string.  It's size is
> not determined by strlen.  strlen are the semantics gty attaches to
> unsigned char * data.  By defeating the type of optabs to being any other
> type, then the length is determined by the ggc subsystem which just knows
> the length of the data (2K on my system).
> 
> I don't really like the type lying going on.  I'd prefer if a tree-core
> person would get honest with the types.
> 
> Another style of fix would be to decide that atomic in this case means
> something else, then, we'd have to have a gty person implement the new
> semantics.  Until that is done, this problem is so bad, that the below
> should go in until someone can fix gty, if someone doesn't want to be
> honest with the type system.
> 
> This bug comes across as a random memory smasher and is incredibly
> annoying to track down.  There is non-determinism in the process and will
> causes non-deterministic memory crashes, but, only on pch use.  To track
> down why, you have to trace back through the pch writing process and
> realize the data in memory is completely valid, is it only the meta
> information about that data that pch uses from the GTY world that causes
> any problem.

Thanks for tracking this down, this sounds like PR59436.  How have you
managed to track it down?  I also wonder why it doesn't seem to affect 4.8
when it also has the same change.

Based on the comments in gengtype.c, I'd expect
  unsigned char *GTY ((atomic, length ("sizeof (struct target_optabs)"))) optabs;
to work (or, perhaps instead of sizeof directly call a function that is
defined in optabs.c and returns that value, perhaps optabs.h isn't included
where it should be), but unfortunately it seems to be rejected right now.

So, the question is how hard would it be to support that.

	Jakub