| Message ID | 20150115111038.GD1405@tucnak.redhat.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek <jakub@redhat.com> wrote: > Hi! > > I ran into -Werror=maybe-uninitialized errors during profiledbootstrap > (../configure --enable-languages=c,c++ --enable-checking=release; > make -j16 profiledboostrap) before I hit a miscompilation I'm going to file. > > Is this ok for trunk, or do we want to work around them differently? I wonder if we can arrange profiledbootstrap to use --disable-werror unless --enable-werror is specified explicitely... Similarly useful if we could do a similar thing from non-standard build-configs... I also wonder if we shouldn't simply fix the uninit pass ... Richard. > 2015-01-14 Jakub Jelinek <jakub@redhat.com> > > * gengtype.c (create_user_defined_type): Workaround > -Wmaybe-uninitialized false positives. > * cse.c (fold_rtx): Likewise. > * loop-invariant.c (gain_for_invariant): Likewise. > > --- gcc/gengtype.c.jj 2015-01-14 17:46:50.000000000 +0100 > +++ gcc/gengtype.c 2015-01-14 18:15:19.285494736 +0100 > @@ -611,7 +611,7 @@ create_user_defined_type (const char *ty > comma-separated list of strings, implicitly assumed to > be type names, potentially with "*" characters. */ > char *arg = open_bracket + 1; > - char *next; > + char *next = NULL; > char *type_id = strtoken (arg, ",>", &next); > pair_p fields = 0; > while (type_id) > --- gcc/cse.c.jj 2015-01-14 17:49:01.000000000 +0100 > +++ gcc/cse.c 2015-01-14 19:02:40.638325329 +0100 > @@ -3093,8 +3093,8 @@ fold_rtx (rtx x, rtx_insn *insn) > int changed = 0; > > /* Operands of X. */ > - rtx folded_arg0; > - rtx folded_arg1; > + rtx folded_arg0 = NULL_RTX; > + rtx folded_arg1 = NULL_RTX; > > /* Constant equivalents of first three operands of X; > 0 when no such equivalent is known. */ > --- gcc/loop-invariant.c.jj 2015-01-14 17:50:10.000000000 +0100 > +++ gcc/loop-invariant.c 2015-01-14 21:13:23.780857707 +0100 > @@ -1268,7 +1268,7 @@ gain_for_invariant (struct invariant *in > bool speed, bool call_p) > { > int comp_cost, size_cost; > - enum reg_class cl; > + enum reg_class cl = NO_REGS; > int ret; > > actual_stamp++; > > Jakub
On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote: > On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek <jakub@redhat.com> wrote: > > Hi! > > > > I ran into -Werror=maybe-uninitialized errors during profiledbootstrap > > (../configure --enable-languages=c,c++ --enable-checking=release; > > make -j16 profiledboostrap) before I hit a miscompilation I'm going to file. > > > > Is this ok for trunk, or do we want to work around them differently? > > I wonder if we can arrange profiledbootstrap to use --disable-werror > unless --enable-werror is specified explicitely... Similarly useful > if we could do a similar thing from non-standard build-configs... For non-standard ones I'm ok, but I've always hoped that profiledbootstrap is considered standard. It certainly worked fine with -Werror at least for us in gcc 4.[4-9]. > I also wonder if we shouldn't simply fix the uninit pass ... If it is possible, sure, but it isn't always the case. We could also just use type var = var; if that is the way to avoid the warnings and not generate extra code. Jakub
On Thu, Jan 15, 2015 at 12:29 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote: >> On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek <jakub@redhat.com> wrote: >> > Hi! >> > >> > I ran into -Werror=maybe-uninitialized errors during profiledbootstrap >> > (../configure --enable-languages=c,c++ --enable-checking=release; >> > make -j16 profiledboostrap) before I hit a miscompilation I'm going to file. >> > >> > Is this ok for trunk, or do we want to work around them differently? >> >> I wonder if we can arrange profiledbootstrap to use --disable-werror >> unless --enable-werror is specified explicitely... Similarly useful >> if we could do a similar thing from non-standard build-configs... > > For non-standard ones I'm ok, but I've always hoped that profiledbootstrap > is considered standard. It certainly worked fine with -Werror at least > for us in gcc 4.[4-9]. Indeed it did (with release checking at least). >> I also wonder if we shouldn't simply fix the uninit pass ... > > If it is possible, sure, but it isn't always the case. > > We could also just use type var = var; if that is the way to avoid > the warnings and not generate extra code. Is that portable though? (legal C, not subject to other compilers that it might be "hineous"...) Anyway, I guess the patch is ok if you add a comment after the inits /* initialize to avoid warnings with profiledbootstrap */ or similar. Otherwise people might be tempted to remove the init again (or wonder why it is there) as it works in regular bootstrap. Thanks, Richard. > Jakub
--- gcc/gengtype.c.jj 2015-01-14 17:46:50.000000000 +0100 +++ gcc/gengtype.c 2015-01-14 18:15:19.285494736 +0100 @@ -611,7 +611,7 @@ create_user_defined_type (const char *ty comma-separated list of strings, implicitly assumed to be type names, potentially with "*" characters. */ char *arg = open_bracket + 1; - char *next; + char *next = NULL; char *type_id = strtoken (arg, ",>", &next); pair_p fields = 0; while (type_id) --- gcc/cse.c.jj 2015-01-14 17:49:01.000000000 +0100 +++ gcc/cse.c 2015-01-14 19:02:40.638325329 +0100 @@ -3093,8 +3093,8 @@ fold_rtx (rtx x, rtx_insn *insn) int changed = 0; /* Operands of X. */ - rtx folded_arg0; - rtx folded_arg1; + rtx folded_arg0 = NULL_RTX; + rtx folded_arg1 = NULL_RTX; /* Constant equivalents of first three operands of X; 0 when no such equivalent is known. */ --- gcc/loop-invariant.c.jj 2015-01-14 17:50:10.000000000 +0100 +++ gcc/loop-invariant.c 2015-01-14 21:13:23.780857707 +0100 @@ -1268,7 +1268,7 @@ gain_for_invariant (struct invariant *in bool speed, bool call_p) { int comp_cost, size_cost; - enum reg_class cl; + enum reg_class cl = NO_REGS; int ret; actual_stamp++;