| Message ID | 20140101230856.GO892@tucnak.redhat.com |
|---|---|
| State | New |
| Headers | show |
On Jan 1, 2014, at 3:08 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote: >> Without any gengtype.c changes, I wonder if just following change wouldn't >> do it, gengtype considers only char and unsigned char pointers as strings >> with the special strlen handling, all other scalar types are treated >> differently it seems, and signed char aliases everything too. >> >> Or s/signed char/void/ in the patch is perhaps even better. > > I've bootstrapped/regtested this on x86_64-linux and i686-linux, > and hopefully verified the problem from the PR is gone, by running over > 610 successful PCH write + PCH read cycles as described in > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures > with the patch, while on a tree from yesterday without the patch I could > reproduce it 17 times, on average every 22 iterations (from 2 to 81). Yup. That sounds like the same bug then. > Ok for trunk (and after a while for 4.8)? I thought my fingers tried this version for some reason… certainly I like this version better than mine. I've tried this, and indeed it fixes my bug, so, I withdraw my version and endorse this one, thanks.
On 01/01/14 16:08, Jakub Jelinek wrote: > On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote: >> Without any gengtype.c changes, I wonder if just following change wouldn't >> do it, gengtype considers only char and unsigned char pointers as strings >> with the special strlen handling, all other scalar types are treated >> differently it seems, and signed char aliases everything too. >> >> Or s/signed char/void/ in the patch is perhaps even better. > > I've bootstrapped/regtested this on x86_64-linux and i686-linux, > and hopefully verified the problem from the PR is gone, by running over > 610 successful PCH write + PCH read cycles as described in > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures > with the patch, while on a tree from yesterday without the patch I could > reproduce it 17 times, on average every 22 iterations (from 2 to 81). > > Ok for trunk (and after a while for 4.8)? > > 2014-01-01 Mike Stump <mikestump@comcast.net> > Jakub Jelinek <jakub@redhat.com> > > PR pch/59436 > * tree-core.h (struct tree_optimization_option): Change optabs > type from unsigned char * to void *. > * optabs.c (init_tree_optimization_optabs): Adjust > TREE_OPTIMIZATION_OPTABS initialization. OK for the trunk. Release managers have final say on 4.8. I hope this was the root cause of the occasional PCH failure I was seeing as well. Jeff
--- gcc/tree-core.h.jj 2013-12-11 10:11:06.000000000 +0100 +++ gcc/tree-core.h 2014-01-01 19:42:15.319869786 +0100 @@ -1550,7 +1550,7 @@ struct GTY(()) tree_optimization_option /* Target optabs for this set of optimization options. This is of type `struct target_optabs *'. */ - unsigned char *GTY ((atomic)) optabs; + void *GTY ((atomic)) optabs; /* The value of this_target_optabs against which the optabs above were generated. */ --- gcc/optabs.c.jj 2013-12-10 12:43:21.000000000 +0100 +++ gcc/optabs.c 2014-01-01 19:43:04.093620067 +0100 @@ -6245,7 +6245,7 @@ init_tree_optimization_optabs (tree optn /* If the optabs changed, record it. */ if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs))) - TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs; + TREE_OPTIMIZATION_OPTABS (optnode) = (void *) tmp_optabs; else { TREE_OPTIMIZATION_OPTABS (optnode) = NULL;