Re: GCC 7.0.1 Status Report (2017-04-20)
On Mon, Apr 24, 2017 at 06:08:15PM +0200, Andreas Krebbel wrote: > On 04/20/2017 12:02 PM, Jakub Jelinek wrote: > > Status > > == > > > > We have reached zero P1 regressions today (and < 100 important > > regressions) and the branches/gcc-7-branch has been created; > > GCC 7.1-rc1 will be built and announced likely tomorrow. > > The branch is now frozen for blocking regressions and documentation > > fixes only, all changes to the branch require a RM approval now. > > I would like to apply the following patches to GCC 7 release branch before > the 7.1 release: > > It took us a few more review cycles than expected. The patches are important > to get reasonable code > for the C11 atomics now being used in Glibc: > > S/390: Optimize atomic_compare_exchange and atomic_compare builtins. > https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00524.html > > These fixes for two GCC 7 regressions: > > S/390: PR80464: Split MEM->GPR vector moves > https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01050.html > > S/390: PR79895: Fix TImode constant handling > https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01049.html > > Any objections? Ok for 7.1, but only if you manage to commit before rc1 is rolled (still waiting for the ARM/AArch64 ABI finalization there), otherwise wait for 7.2. Jakub
Re: Alias analysis and zero-sized arrays vs. flexible arrays
On Tue, Apr 25, 2017 at 1:06 AM, Steve Ellcey wrote:
> I was wondering if someone could help me understand a bug involving
> aliasing, this is happening on aarch64 but I don't think it is architecure
> specific. The problem involves flexible arrays vs. zero sized arrays at
> the end of a structure.
>
> In the original code, a zero size array is used and the program does not
> behave correctly, if the zero sized array is changed to a C99 flexible
> array it does work. Are there any reasons why a zero-size array and
> a flexible array should behave differently?
>
> I was able to cut the test case down into the attached (non-runnable) test
> case which when compiled with -O2 for aarch64 generates different code
> with -DFLEX and -UFLEX. In the code for the main loop GCC generates a
> ldr/str/ldr/str sequence (with other instructions) when using a flexible
> array and a ldr/ldr/str/str sequence when using a zero size array. Moving
> the second ldr ahead of the first str is what is causing the problem in the
> original test case.
>
> I have tracked the change in behaviour to differences in alias analysis
> and to the get_ref_base_and_extent routine in tree-dfa.c and it looks
> like the 'tree exp' argument is different between the two versions but
> I am not sure if it should be different and, if the difference is OK,
> should that affect how get_ref_base_and_extent behaves, as it apparently
> does.
>
> Steve Ellcey
> sell...@cavium.com
>
>
>
> Test case, compiling with '-O2 -DFLEX' generates different code than
> '-O2 -UFLEX' on aarch64 using ToT GCC. A cross compiler built on x86
> can reproduce the problem too.
>
> ---
>
>
> struct q {
> int b;
> };
> struct r {
>int n;
>struct q slot[0];
> };
> struct s {
>int n;
> #ifdef FLEX
> long int o[];
> #else
> long int o[0];
> #endif
> };
> extern int x, y, m;
> extern struct s *a;
> extern struct r *b;
> extern void bar();
> int foo() {
>int i,j;
>for (i = 0; i < m; i++) {
> a->o[i] = sizeof(*a);
> b = ((struct r *)(((char *)a) + a->o[a->n]));
> for (j = 0; j < 10; j++) {
> b->slot[j].b = 0;
in case b->slot[j].b aliases a->o[i] or a->o[a->n]
you invoke undefined behavior becuase you violate
strict aliasing rules. I don't know why there's a
difference between -DFLEX and -UFLEX but your
code is buggy even if it works in one case.
Richard.
> }
> bar();
> }
> }
Re: GCC 7.0.1 Status Report (2017-04-20)
On 04/25/2017 12:25 PM, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 06:08:15PM +0200, Andreas Krebbel wrote: >> On 04/20/2017 12:02 PM, Jakub Jelinek wrote: >>> Status >>> == >>> >>> We have reached zero P1 regressions today (and < 100 important >>> regressions) and the branches/gcc-7-branch has been created; >>> GCC 7.1-rc1 will be built and announced likely tomorrow. >>> The branch is now frozen for blocking regressions and documentation >>> fixes only, all changes to the branch require a RM approval now. >> >> I would like to apply the following patches to GCC 7 release branch before >> the 7.1 release: >> >> It took us a few more review cycles than expected. The patches are >> important to get reasonable code >> for the C11 atomics now being used in Glibc: >> >> S/390: Optimize atomic_compare_exchange and atomic_compare builtins. >> https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00524.html >> >> These fixes for two GCC 7 regressions: >> >> S/390: PR80464: Split MEM->GPR vector moves >> https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01050.html >> >> S/390: PR79895: Fix TImode constant handling >> https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01049.html >> >> Any objections? > > Ok for 7.1, but only if you manage to commit before rc1 is rolled > (still waiting for the ARM/AArch64 ABI finalization there), > otherwise wait for 7.2. Ok. Done. -Andreas-
Who broke options.h?
Someone (other than Richard who seems to have fixed his bootstrap issue) in the last 3 days has broken bootstrap on FreeBSD. The generated file gcc/options.h contains code of the form OPT_C = 116, /* -C */ OPT_CC = 117, /* -CC */ OPT_c = 118, /* -c */ OPT_C = 119, /* -C */ OPT_coverage = 120,/* -coverage */ OPT_cpp_ = 121,/* -cpp= */ OPT_cpp = 122, /* -cpp */ OPT_d = 123, /* -d */ OPT_D = 124, /* -D */ OPT_d = 125, /* -d */ OPT_defsym_ = 126, /* -defsym= */ OPT_defsym = 127, /* -defsym */ OPT_d = 128, /* -d */ OPT_D = 129, /* -D */ The sudden dumping ground of everyone's pet project into trunk after the new branch has been created is making it impossible to bisect this issue. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, 2017-04-25 at 06:59 -0700, Steve Kargl wrote:
> Someone (other than Richard who seems to have fixed his
> bootstrap issue) in the last 3 days has broken bootstrap
> on FreeBSD. The generated file gcc/options.h contains
> code of the form
>
> OPT_C = 116, /* -C */
> OPT_CC = 117, /* -CC */
> OPT_c = 118, /* -c */
> OPT_C = 119, /* -C */
> OPT_coverage = 120,/* -coverage */
> OPT_cpp_ = 121,/* -cpp= */
> OPT_cpp = 122, /* -cpp */
> OPT_d = 123, /* -d */
> OPT_D = 124, /* -D */
> OPT_d = 125, /* -d */
> OPT_defsym_ = 126, /* -defsym= */
> OPT_defsym = 127, /* -defsym */
> OPT_d = 128, /* -d */
> OPT_D = 129, /* -D */
>
> The sudden dumping ground of everyone's pet project into
> trunk after the new branch has been created is making it
> impossible to bisect this issue.
Presumably the issue is the duplicate names within an enum. Above,
OPT_C has values 116, 119
OPT_d has values 123, 125, 128
OPT_D has values 124, 129
etc.
Looking at the code that writes out that enum in opth-gen.awk, I see:
443 enum_value = 0
444 for (i = 0; i < n_opts; i++) {
445 # Combine the flags of identical switches. Switches
446 # appear many times if they are handled by many front
447 # ends, for example.
448 while( i + 1 != n_opts && opts[i] == opts[i + 1] ) {
449 flags[i + 1] = flags[i] " " flags[i + 1];
450 i++;
451 }
Lines 445-451 suggest that the options are meant to be in some kind of
sorted order, so that duplicates will be adjacent.
In the output you posted the duplicates are *not* adjacent. So is
there some implicit assumption in the awk code about the sorting of
options, that somehow isn't satisfied on the machine you're seeing this
on?
>From what I can tell, the n_opts and opts in that file come direct from
opt-read.awk, which gets them from opt-gather.awk, which appears to
sort them (but my awk skills are weak).
Alternatively, maybe the collisions are caused by some names needing
opt_sanitized_name? (you could try making that return its argumen
unmodified to see if it shows anything, I guess) But I don't see any
new option in trunk in the last 3 days.
Hope this is helpful
Dave
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 11:03 AM, David Malcolm wrote:
> On Tue, 2017-04-25 at 06:59 -0700, Steve Kargl wrote:
>> Someone (other than Richard who seems to have fixed his
>> bootstrap issue) in the last 3 days has broken bootstrap
>> on FreeBSD. The generated file gcc/options.h contains
>> code of the form
>>
>> OPT_C = 116, /* -C */
>> OPT_CC = 117, /* -CC */
>> OPT_c = 118, /* -c */
>> OPT_C = 119, /* -C */
>> OPT_coverage = 120,/* -coverage */
>> OPT_cpp_ = 121,/* -cpp= */
>> OPT_cpp = 122, /* -cpp */
>> OPT_d = 123, /* -d */
>> OPT_D = 124, /* -D */
>> OPT_d = 125, /* -d */
>> OPT_defsym_ = 126, /* -defsym= */
>> OPT_defsym = 127, /* -defsym */
>> OPT_d = 128, /* -d */
>> OPT_D = 129, /* -D */
>>
>> The sudden dumping ground of everyone's pet project into
>> trunk after the new branch has been created is making it
>> impossible to bisect this issue.
>
> Presumably the issue is the duplicate names within an enum. Above,
> OPT_C has values 116, 119
> OPT_d has values 123, 125, 128
> OPT_D has values 124, 129
> etc.
>
> Looking at the code that writes out that enum in opth-gen.awk, I see:
>
>443 enum_value = 0
>444 for (i = 0; i < n_opts; i++) {
>445 # Combine the flags of identical switches. Switches
>446 # appear many times if they are handled by many front
>447 # ends, for example.
>448 while( i + 1 != n_opts && opts[i] == opts[i + 1] ) {
>449 flags[i + 1] = flags[i] " " flags[i + 1];
>450 i++;
>451 }
>
> Lines 445-451 suggest that the options are meant to be in some kind of
> sorted order, so that duplicates will be adjacent.
>
> In the output you posted the duplicates are *not* adjacent. So is
> there some implicit assumption in the awk code about the sorting of
> options, that somehow isn't satisfied on the machine you're seeing this
> on?
>
> From what I can tell, the n_opts and opts in that file come direct from
> opt-read.awk, which gets them from opt-gather.awk, which appears to
> sort them (but my awk skills are weak).
>
> Alternatively, maybe the collisions are caused by some names needing
> opt_sanitized_name? (you could try making that return its argumen
> unmodified to see if it shows anything, I guess) But I don't see any
> new option in trunk in the last 3 days.
Maybe BSD awk versus GNU awk?
Did the bootstrap system change or GNU awk is not in the path?
- David
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 11:03:40AM -0400, David Malcolm wrote: > >From what I can tell, the n_opts and opts in that file come direct from > opt-read.awk, which gets them from opt-gather.awk, which appears to > sort them (but my awk skills are weak). Perhaps a bug in the FreeBSD awk? The *.awk files haven't changed since February, and the last modification of any *.opt file has been in r247028 5 days ago. Jakub
Re: Who broke options.h?
On Apr 25 2017, Steve Kargl wrote: > Someone (other than Richard who seems to have fixed his > bootstrap issue) in the last 3 days has broken bootstrap > on FreeBSD. Did you change your locale since then? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Who broke options.h?
On Tue, 25 Apr 2017, David Malcolm wrote: > >From what I can tell, the n_opts and opts in that file come direct from > opt-read.awk, which gets them from opt-gather.awk, which appears to > sort them (but my awk skills are weak). Maybe the opt-gather.awk call in Makefile.in needs to set LC_ALL=C. If setting LC_ALL=C on the $(AWK) -f $(srcdir)/opt-gather.awk call works to fix this then that change is preapproved. -- Joseph S. Myers jos...@codesourcery.com
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 11:09:05AM -0400, David Edelsohn wrote: > > > > From what I can tell, the n_opts and opts in that file come direct from > > opt-read.awk, which gets them from opt-gather.awk, which appears to > > sort them (but my awk skills are weak). > > > > Alternatively, maybe the collisions are caused by some names needing > > opt_sanitized_name? (you could try making that return its argumen > > unmodified to see if it shows anything, I guess) But I don't see any > > new option in trunk in the last 3 days. > > Maybe BSD awk versus GNU awk? > > Did the bootstrap system change or GNU awk is not in the path? > This did occur with nawk. But, I think that there must be something environmental setting on the user account causing the problem. If I login as the user that owns the gcc/ account, I see the problem. If I login to my normal account and then su to the gcc/ account, the system builds as normal. I'm investigating. On the bright side, I can confirm that Richard's patch does fix the original issue. Thanks, Richard. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 04:13:45PM +, Joseph Myers wrote: > On Tue, 25 Apr 2017, David Malcolm wrote: > > > >From what I can tell, the n_opts and opts in that file come direct from > > opt-read.awk, which gets them from opt-gather.awk, which appears to > > sort them (but my awk skills are weak). > > Maybe the opt-gather.awk call in Makefile.in needs to set LC_ALL=C. If > setting LC_ALL=C on the $(AWK) -f $(srcdir)/opt-gather.awk call works to > fix this then that change is preapproved. > I think you've found the problem. If I login as the user that owns the gcc/ directory, I see the problem. That user has troutmask:sgk[202] locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= If I login into my normal account and then su to user sgk, the problem does not occur. My normal account has troutmask:kargl[201] locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE=C LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= So, it appears that LC_COLLATE=C is needed. I'll see if I can come up with a patch later today. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > On Apr 25 2017, Steve Kargl wrote: > > > Someone (other than Richard who seems to have fixed his > > bootstrap issue) in the last 3 days has broken bootstrap > > on FreeBSD. > > Did you change your locale since then? > See my reply to Joseph. It is locale related. I'm surprised I haven't seen this before, which suggests that I must always login into my normal account and then su to the gcc/ account. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 09:54:04AM -0700, Steve Kargl wrote: > On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > > On Apr 25 2017, Steve Kargl wrote: > > > > > Someone (other than Richard who seems to have fixed his > > > bootstrap issue) in the last 3 days has broken bootstrap > > > on FreeBSD. > > > > Did you change your locale since then? > > > > See my reply to Joseph. It is locale related. I'm surprised > I haven't seen this before, which suggests that I must always > login into my normal account and then su to the gcc/ account. So like (to follow how we set env vars in other spots): * Makefile.in (s-options): Call opt-gather.awk with LC_ALL=C in the environment. --- gcc/Makefile.in 2017-04-18 21:16:24.703775156 +0200 +++ gcc/Makefile.in 2017-04-25 18:56:58.304963926 +0200 @@ -2139,6 +2139,7 @@ s-specs : Makefile optionlist: s-options ; @true s-options: $(ALL_OPT_FILES) Makefile $(srcdir)/opt-gather.awk + LC_ALL=C ; export LC_ALL ; \ $(AWK) -f $(srcdir)/opt-gather.awk $(ALL_OPT_FILES) > tmp-optionlist $(SHELL) $(srcdir)/../move-if-change tmp-optionlist optionlist $(STAMP) s-options ? Untested. Jakub
Re: Who broke options.h?
On Tue, 25 Apr 2017, Jakub Jelinek wrote: > On Tue, Apr 25, 2017 at 09:54:04AM -0700, Steve Kargl wrote: > > On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > > > On Apr 25 2017, Steve Kargl wrote: > > > > > > > Someone (other than Richard who seems to have fixed his > > > > bootstrap issue) in the last 3 days has broken bootstrap > > > > on FreeBSD. > > > > > > Did you change your locale since then? > > > > > > > See my reply to Joseph. It is locale related. I'm surprised > > I haven't seen this before, which suggests that I must always > > login into my normal account and then su to the gcc/ account. > > So like (to follow how we set env vars in other spots): > > * Makefile.in (s-options): Call opt-gather.awk with > LC_ALL=C in the environment. Yes, assuming this fixes the problem. -- Joseph S. Myers jos...@codesourcery.com
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 06:58:56PM +0200, Jakub Jelinek wrote: > On Tue, Apr 25, 2017 at 09:54:04AM -0700, Steve Kargl wrote: > > On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > > > On Apr 25 2017, Steve Kargl wrote: > > > > > > > Someone (other than Richard who seems to have fixed his > > > > bootstrap issue) in the last 3 days has broken bootstrap > > > > on FreeBSD. > > > > > > Did you change your locale since then? > > > > > > > See my reply to Joseph. It is locale related. I'm surprised > > I haven't seen this before, which suggests that I must always > > login into my normal account and then su to the gcc/ account. > > So like (to follow how we set env vars in other spots): > > * Makefile.in (s-options): Call opt-gather.awk with > LC_ALL=C in the environment. > > --- gcc/Makefile.in 2017-04-18 21:16:24.703775156 +0200 > +++ gcc/Makefile.in 2017-04-25 18:56:58.304963926 +0200 > @@ -2139,6 +2139,7 @@ s-specs : Makefile > > optionlist: s-options ; @true > s-options: $(ALL_OPT_FILES) Makefile $(srcdir)/opt-gather.awk > + LC_ALL=C ; export LC_ALL ; \ > $(AWK) -f $(srcdir)/opt-gather.awk $(ALL_OPT_FILES) > tmp-optionlist > $(SHELL) $(srcdir)/../move-if-change tmp-optionlist optionlist > $(STAMP) s-options > > ? Untested. I can test this. However, as this is a change in Makefile.in, do I need to add --enable-maintainer-mode or some such flag to configure? -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 10:18:28AM -0700, Steve Kargl wrote: > > --- gcc/Makefile.in 2017-04-18 21:16:24.703775156 +0200 > > +++ gcc/Makefile.in 2017-04-25 18:56:58.304963926 +0200 > > @@ -2139,6 +2139,7 @@ s-specs : Makefile > > > > optionlist: s-options ; @true > > s-options: $(ALL_OPT_FILES) Makefile $(srcdir)/opt-gather.awk > > + LC_ALL=C ; export LC_ALL ; \ > > $(AWK) -f $(srcdir)/opt-gather.awk $(ALL_OPT_FILES) > tmp-optionlist > > $(SHELL) $(srcdir)/../move-if-change tmp-optionlist optionlist > > $(STAMP) s-options > > > > ? Untested. > > I can test this. However, as this is a change in Makefile.in, > do I need to add --enable-maintainer-mode or some such flag > to configure? No. Makefile is not included, so it is always (re)generated. Jakub
Re: Alias analysis and zero-sized arrays vs. flexible arrays
On Tue, 2017-04-25 at 12:53 +0200, Richard Biener wrote:
> > int foo() {
> > int i,j;
> > for (i = 0; i < m; i++) {
> > a->o[i] = sizeof(*a);
> > b = ((struct r *)(((char *)a) + a->o[a->n]));
> > for (j = 0; j < 10; j++) {
> > b->slot[j].b = 0;
> in case b->slot[j].b aliases a->o[i] or a->o[a->n]
> you invoke undefined behavior becuase you violate
> strict aliasing rules. I don't know why there's a
> difference between -DFLEX and -UFLEX but your
> code is buggy even if it works in one case.
>
> Richard.
Should this work if I use -fno-strict-alias? Even with that option I
get different code with a zero-sized array vs. a flexible array.
I have a patch to get_ref_base_and_extent that changes the behaviour
for zero-length arrays and I will submit it after I have tested it.
Steve Ellcey
sell...@cavium.com
Re: Alias analysis and zero-sized arrays vs. flexible arrays
On April 25, 2017 8:03:20 PM GMT+02:00, Steve Ellcey wrote:
>On Tue, 2017-04-25 at 12:53 +0200, Richard Biener wrote:
>
>> > int foo() {
>> > int i,j;
>> > for (i = 0; i < m; i++) {
>> > a->o[i] = sizeof(*a);
>> > b = ((struct r *)(((char *)a) + a->o[a->n]));
>> > for (j = 0; j < 10; j++) {
>> > b->slot[j].b = 0;
>> in case b->slot[j].b aliases a->o[i] or a->o[a->n]
>> you invoke undefined behavior becuase you violate
>> strict aliasing rules. I don't know why there's a
>> difference between -DFLEX and -UFLEX but your
>> code is buggy even if it works in one case.
>>
>> Richard.
>
>Should this work if I use -fno-strict-alias?
Yes.
Even with that option I
>get different code with a zero-sized array vs. a flexible array.
>I have a patch to get_ref_base_and_extent that changes the behaviour
>for zero-length arrays and I will submit it after I have tested it.
OK. I briefly skimmed get_ref_base_and_extent and didn't see where it would
make a difference. Your patch should make that obvious (and allow for a much
shorter testcase).
Richard.
>Steve Ellcey
>sell...@cavium.com
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 06:58:56PM +0200, Jakub Jelinek wrote: > On Tue, Apr 25, 2017 at 09:54:04AM -0700, Steve Kargl wrote: > > On Tue, Apr 25, 2017 at 05:46:15PM +0200, Andreas Schwab wrote: > > > On Apr 25 2017, Steve Kargl wrote: > > > > > > > Someone (other than Richard who seems to have fixed his > > > > bootstrap issue) in the last 3 days has broken bootstrap > > > > on FreeBSD. > > > > > > Did you change your locale since then? > > > > > > > See my reply to Joseph. It is locale related. I'm surprised > > I haven't seen this before, which suggests that I must always > > login into my normal account and then su to the gcc/ account. > > So like (to follow how we set env vars in other spots): > > * Makefile.in (s-options): Call opt-gather.awk with > LC_ALL=C in the environment. > > --- gcc/Makefile.in 2017-04-18 21:16:24.703775156 +0200 > +++ gcc/Makefile.in 2017-04-25 18:56:58.304963926 +0200 > @@ -2139,6 +2139,7 @@ s-specs : Makefile > > optionlist: s-options ; @true > s-options: $(ALL_OPT_FILES) Makefile $(srcdir)/opt-gather.awk > + LC_ALL=C ; export LC_ALL ; \ > $(AWK) -f $(srcdir)/opt-gather.awk $(ALL_OPT_FILES) > tmp-optionlist > $(SHELL) $(srcdir)/../move-if-change tmp-optionlist optionlist > $(STAMP) s-options > > ? Untested. > This appears to fix my problem. Do you want to commit the patch or would you rather have me do it? Note, the problem is present in 7-branch. I haven't checked the other branches. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Re: Who broke options.h?
On Tue, Apr 25, 2017 at 12:43:00PM -0700, Steve Kargl wrote: > This appears to fix my problem. Do you want to commit the patch > or would you rather have me do it? Note, the problem is present > in 7-branch. I haven't checked the other branches. Committed to trunk, 7.x will need to wait until 7.1 is released, the rc1 is already in the works and this isn't anything new, I see the same thing already in GCC 4.0. Jakub
suggestion: c compiler warning for failure to test result
A possibly useful addition similar to:
__attribute__((warn_unused_result))
might be
__attribute__((warn_untested_result))
for things like allocation failures that
are not verified before use.
For instance:
void *malloc(size_t size);
could become
void * __attribute((warn_untested_result)) malloc(size_t size)
so that
#include
struct foo {
int bar;
};
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
baz->bar = 1;
return baz;
}
The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.
struct foo *alloc_foo(void)
{
struct foo *baz =
malloc(sizeof(struct foo));
if (baz) baz->bar = 1;
return
baz;
}
Similarly, alloc_foo could use that new attribute.
GCC 7.1 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 7.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.0.1-RC-20170425 and shortly its mirrors. It has been generated from SVN revision 247264. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 7.1 on Tuesday, May 2nd.
gcc-5-20170425 is now available
Snapshot gcc-5-20170425 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170425/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 247269 You'll find: gcc-5-20170425.tar.bz2 Complete GCC SHA256=193cb71f178feee597e5ca38aee014b4b0c8364fd51efd0d9c973cfdaf4e8331 SHA1=b763d368ef993d279bbd99fbde000c53f9082b74 Diffs from 5-20170418 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: suggestion: c compiler warning for failure to test result
On 04/25/2017 02:35 PM, Joe Perches wrote:
A possibly useful addition similar to:
__attribute__((warn_unused_result))
might be
__attribute__((warn_untested_result))
for things like allocation failures that
are not verified before use.
I agree that this would be a useful feature. In fact, I've been
thinking about implementing something like it, though not quite
as general. (My initial thought was to key the warning off
an existing attribute like alloc_size for functions that aren't
also decorated with returns_nonnull.) With warn_untested_result
even non-allocation functions (such as fopen) could be decorated,
so that seems like a better approach.
Can you please open an enhancement request in Bugzilla?
Thanks
Martin
For instance:
void *malloc(size_t size);
could become
void * __attribute((warn_untested_result)) malloc(size_t size)
so that
#include
struct foo {
int bar;
};
struct foo *alloc_foo(void)
{
struct foo *baz = malloc(sizeof(struct foo));
baz->bar = 1;
return baz;
}
The compiler could emit a warning on the set
of baz->bar as an intermediate test of baz
is not performed before any use of baz.
struct foo *alloc_foo(void)
{
struct foo *baz =
malloc(sizeof(struct foo));
if (baz) baz->bar = 1;
return
baz;
}
Similarly, alloc_foo could use that new attribute.
