Re: GCC and out-of-range constant array indexes?
On 10/07/10 21:24:18, Ian Lance Taylor wrote: > -Warray-bounds, but that is one of the warnings which is unfortunately > only available when optimizing. In this case it requires -O2. Ian, thanks. I had thought optimization might be involved, but didn't try -O2. > There was an attempt a couple of years ago to implement this warning > when not optimizing [...]. Would it be possible to compute enough of the control flow graph to process warnings like this one, without running the actual optimizations, unless those optimizations are requested? Would the cost be too high? - Gary
Re: RFE: 'enable checking' as a GCC compilation switch?
On 10/03/10 12:03:44, Ian Lance Taylor wrote: > You will need to try a sample implementation and see how much the > compiler slows down and how much bigger it gets. I began roughing out the required changes. This will be a background project. If I can finish it to the point of running some timing tests, I will post the results here. thanks, - Gary
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Thu, Sep 23, 2010 at 9:53 AM, NightStrike wrote: > On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn wrote: >> On 21/09/2010 02:51, NightStrike wrote: >> >>> The toolchain is broken once again here: >>> >>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. >>> -I../../../build/mingw/mingw-w64-crt >>> -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD >>> -I/tmp/build/root/x >>> 86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat >>> -Wstrict-ali >>> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration >>> -Wmissing-noret >>> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD >>> -MP -MF >>> math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o >>> math/lib32_libmingwex_a-sf_erf.o >>> `test -f 'math/sf_erf.c' || echo >>> '../../../build/mingw/mingw-w64-crt/'`math/sf_ >>> erf.c >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function >>> `__trunc_float_wor >>> d.isra.0': >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler >>> error: >>> tree check: expected var_decl, have debug_expr_decl in >>> const_value_known_p, at >>> varpool.c:375 >> >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 >> >> cheers, >> DaveK >> > > Thanks. Hope it gets fixed fast. I will post a new testsuite once > that bug is closed. > http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 8 October 2010 16:56, NightStrike wrote: > > http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html There are a lot of failures there, including quite a few tests which don't look platform-dependent. Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see what's failing? A lot of them look locale-related, so could just be disabled if the platform doesn't support them. Others are more concerning and shouldn't be failing on any platform.
Re: End of GCC 4.6 Stage 1: October 27, 2010
2010/10/8 Jonathan Wakely :
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
> what's failing? A lot of them look locale-related, so could just be
> disabled if the platform doesn't support them. Others are more
> concerning and shouldn't be failing on any platform.
>
The locale stuff is related to printf-family and 'long double' types.
Here is a special handling for printf functions necessary to use here
instead the gnu-version of printf-family (_mingw_ routines) we
provide.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: GCC and out-of-range constant array indexes?
On Fri, 8 Oct 2010 08:14:23 -0700
Gary Funck wrote:
> On 10/07/10 21:24:18, Ian Lance Taylor wrote:
> > -Warray-bounds, but that is one of the warnings which is unfortunately
> > only available when optimizing. In this case it requires -O2.
>
> Ian, thanks. I had thought optimization might be involved, but didn't try
> -O2.
>
> Would it be possible to compute enough of the control flow graph
> to process warnings like this one, without running the
> actual optimizations, unless those optimizations are requested?
> Would the cost be too high?
I am not an expert on these optimizations, but why would you want that?
The optimizations involved are indeed expensive (otherwise it would be
-O1 not -O2), but once you asked for them, why only get warnings
without the code generation improvement? (I am assuming that the
required computations in the compiler are mostly in the middle end, and
that getting such warnings are a side effect).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
On 10/08/10 18:38:29, Basile Starynkevitch wrote: > I am not an expert on these optimizations, but why would you want that? I routinely compile/build with "-O0 -g3" because the code is easier to debug. I also admit that I compile/build with "-O0" because it is faster than "-O2" or "-O3" for example, and during development I am more interested in faster turn-around time on builds than faster execution time. Also, when I compile/build projects, I try to use the maximum level of warnings and checking that the source code base will support. I am willing to trade off some support/build time in favor of more thorough warnings. - Gary
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely wrote: > On 8 October 2010 16:56, NightStrike wrote: >> >> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html > > There are a lot of failures there, including quite a few tests which > don't look platform-dependent. > > Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see > what's failing? A lot of them look locale-related, so could just be > disabled if the platform doesn't support them. Others are more > concerning and shouldn't be failing on any platform. > Sent log offlist
Re: GCC and out-of-range constant array indexes?
Gary Funck writes: >> There was an attempt a couple of years ago to implement this warning >> when not optimizing [...]. > > Would it be possible to compute enough of the control flow graph > to process warnings like this one, without running the > actual optimizations, unless those optimizations are requested? > Would the cost be too high? I think it could be done but I don't think it would be simple. I do think it would be a good idea to make warnings independent of optimization level, except for those warnings like -Wstrict-aliasing which are specifically about optimizations. Ian
Re: GCC and out-of-range constant array indexes?
On Fri, 8 Oct 2010 09:54:07 -0700
Gary Funck wrote:
> On 10/08/10 18:38:29, Basile Starynkevitch wrote:
> > I am not an expert on these optimizations, but why would you want that?
>
> I routinely compile/build with "-O0 -g3" because the code is easier to debug.
> I
> also admit that I compile/build with "-O0" because it is faster than
> "-O2" or "-O3" for example, and during development I am more interested
> in faster turn-around time on builds than faster execution time.
I understand that. Using "-O1 -g3" is a suitable compromise also.
>
> Also, when I compile/build projects, I try to use the maximum level of
> warnings
> and checking that the source code base will support. I am willing to trade
> off some support/build time in favor of more thorough warnings.
You could build both a release version with "-O2" or "-O2 -g" and a
development version with "-O0 -g3".
Howeer, I see a logic in needing -O2 to get some warnings.
Optimizations are expensive, and they compute static properties of the
source code, which are usable (& necessary and used) for additional
warnings.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
Basile Starynkevitch writes: > Howeer, I see a logic in needing -O2 to get some warnings. > Optimizations are expensive, and they compute static properties of the > source code, which are usable (& necessary and used) for additional > warnings. The problem that I think we've discovered over the years is that when warnings depend on optimizations, the warnings are unstable. It means that as optimizations change, the warnings appear and disappear. And that means that as people move their code to new compiler releases, they get unpredictable new warnings. That can be OK when the warnings are always true positives. However, it is very problematic when the warnings are sometimes false positives, because it forces people to change their code for no reason, or to disable the warning. It might seem to be something like an out of bounds constant array index can not go wrong, in the sense that it can never give a false positive. However, we have already seen that it can go wrong if the compiler does not reliably ignore code which is not executed. Another reason that it's problematic to have warnings depend on optimization level is that many people develop with -O0, and we want to give them as many true positive warnings at that level as we can. Ian
Re: End of GCC 4.6 Stage 1: October 27, 2010
Most of the failing libstdc++ tests which shouldn't be platform-dependent fail with this message: sh: /usr/bin/stty: Bad address libstdc++-v3/config/os/mingw32/error_constants.h is missing several entries, causing failures in the 19_diagnostics tests. There are a few failures in 23_containers/vector/ext_pointer which might be caused by an inttype definition on the platform, I'm not sure. A bugzilla PR should probably be opened if there isn't one already.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely wrote: > Most of the failing libstdc++ tests which shouldn't be > platform-dependent fail with this message: > sh: /usr/bin/stty: Bad address This Bad address stuff is due to some conflict with cygwin. We really need to work with cygwin folks to find a proper fix, but are having difficulty. Dave, can you work with Kai to help troubleshoot that, by any chance?
Re: GCC and out-of-range constant array indexes?
On Fri, 08 Oct 2010 11:03:27 -0700
Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
> > Howeer, I see a logic in needing -O2 to get some warnings.
> > Optimizations are expensive, and they compute static properties of the
> > source code, which are usable (& necessary and used) for additional
> > warnings.
>
> The problem that I think we've discovered over the years is that when
> warnings depend on optimizations, the warnings are unstable. It means
> that as optimizations change, the warnings appear and disappear. And
> that means that as people move their code to new compiler releases, they
> get unpredictable new warnings.
Is this unstability of warnings related to the (perhaps stupid)
folklore of avoiding -O3 (what I mean is that, for instance, most Linux
distributions are built with -O2 at most; very few are using -O3; this
brings a chicken & egg issue: since -O3 is much less used, it is
probably more buggy & less usable!).
But I also noticed (even on the runtime inside the MELT branch of GCC)
that newer GCC releases give better & more warnings than older ones.
(BTW, Ian, I am still hoping for your review & ok of my gengtype patches!).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: GCC and out-of-range constant array indexes?
How about the following: 1) Default warnings are cheap, and work fine at -O0. 2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused) [not sure about the actual list] that require optimizations, will issue a Warning when they are requested, but the appropriate optimization level has not been asserted, that is required for those warnings to work in their maximal fashion. Or: Specification of the expensive warnings will cause appropriate control flow computations that are required to support those warning levels. (as suggested previously)
Re: GCC and out-of-range constant array indexes?
Gary Funck writes: > 2) Expensive warnings (-Wall, -Warray-bounds, -Wuninitialized, -Wunused) > [not sure about the actual list] that require optimizations, will issue > a Warning when they are requested, but the appropriate optimization level > has not been asserted, that is required for those warnings to work in their > maximal fashion. > > Or: > > Specification of the expensive warnings will cause appropriate > control flow computations that are required to support those > warning levels. (as suggested previously) I think both of those alternatives would be surprising and easily misunderstood behaviour for many compiler users. The first means that you have to use different warnings at different optimization levels, or you need to use some mechanism to disable the default warning. The second means that adding a warning option could have a significant effect on compile time, which is surprising. My current thinking is that the following should be followed by all warnings: * They should be entirely independent of optimization level, or * They should warn specifically about the consequences of some easily misunderstood optimization, or * They should always be true positives. Almost all current warnings already meet those requirements; the main problem child is -Wuninitialized. Ian
Re: GCC and out-of-range constant array indexes?
On 10/08/10 13:22:46, Ian Lance Taylor wrote: > I think both of those alternatives would be surprising and easily > misunderstood behaviour for many compiler users. [...] I find the following behavior to be surprising: $ gcc -Warray-bounds -O0 -c t.c $ gcc -Warray-bounds -O1 -c t.c $ gcc -Warray-bounds -O2 -c t.c t.c: In function ‘main’: t.c:6: warning: array subscript is above array bounds t.c:7: warning: array subscript is below array bounds The impact is that I may think that after I build my project at -O0 or -O1, with various warnings enabled, that there are potential surprises that await, when I perform a production build at -O2 and higher. It makes perfect sense to me that the following happens: $ gcc -Warray-bounds -O1 -c t.c t.c: Warning: -Warray-bounds has no effect unless compiled with optimization level -O2 and higher. > Almost all current warnings already meet those requirements; the main > problem child is -Wuninitialized. ... and -Warray-bounds?
RE: GCC and out-of-range constant array indexes?
> The impact is that I may think that after I build my project at > -O0 or -O1, with various warnings enabled, that there are > potential surprises that await, when I perform a production build > at -O2 and higher. -Warray-bounds warnings can also be triggered only when using the aggressive inlining optimizations enabled by -O3. I assume the same is true for -flto, which would allow for a cross-module inlining and therefore deeper analysis. I personally just use PC-Lint as an extra safety net to help find issues like this during my necessarily short TDD cycle. Then when the optimized build is compiled, all of the issues that GCC would have found were generally already found by PC-Lint. It's quite nice to have the two tools cross-check each other in a usage pattern that they are both well-suited to.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, 8 Oct 2010, NightStrike wrote: > On Thu, Sep 23, 2010 at 9:53 AM, NightStrike wrote: > > On Tue, Sep 21, 2010 at 9:26 AM, Dave Korn > > wrote: > >> On 21/09/2010 02:51, NightStrike wrote: > >> > >>> The toolchain is broken once again here: > >>> > >>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. > >>> -I../../../build/mingw/mingw-w64-crt > >>> -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD > >>> -I/tmp/build/root/x > >>> 86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat > >>> -Wstrict-ali > >>> asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration > >>> -Wmissing-noret > >>> urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD > >>> -MP -MF > >>> math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o > >>> math/lib32_libmingwex_a-sf_erf.o > >>> `test -f 'math/sf_erf.c' || echo > >>> '../../../build/mingw/mingw-w64-crt/'`math/sf_ > >>> erf.c > >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function > >>> `__trunc_float_wor > >>> d.isra.0': > >>> ../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler > >>> error: > >>> tree check: expected var_decl, have debug_expr_decl in > >>> const_value_known_p, at > >>> varpool.c:375 > >> > >> > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738 > >> > >> cheers, > >> DaveK > >> > > > > Thanks. Hope it gets fixed fast. I will post a new testsuite once > > that bug is closed. > > > > http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html Please also post results for the 4.5 branch. I think it doesn't make any sense to include a target in the list of primary or secondary targets if it didn't work reasonably for at least one release. Thanks, Richard.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther wrote: > Please also post results for the 4.5 branch. I think it doesn't make > any sense to include a target in the list of primary or secondary > targets if it didn't work reasonably for at least one release. > > Thanks, > Richard. Ok. Does that have to be done regularly?
Re: GCC and out-of-range constant array indexes?
Gary Funck writes:
> On 10/08/10 13:22:46, Ian Lance Taylor wrote:
>> I think both of those alternatives would be surprising and easily
>> misunderstood behaviour for many compiler users. [...]
>
> I find the following behavior to be surprising:
>
> $ gcc -Warray-bounds -O0 -c t.c
> $ gcc -Warray-bounds -O1 -c t.c
> $ gcc -Warray-bounds -O2 -c t.c
> t.c: In function ‘main’:
> t.c:6: warning: array subscript is above array bounds
> t.c:7: warning: array subscript is below array bounds
>
> The impact is that I may think that after I build my project at
> -O0 or -O1, with various warnings enabled, that there are
> potential surprises that await, when I perform a production build
> at -O2 and higher.
>
> It makes perfect sense to me that the following happens:
>
> $ gcc -Warray-bounds -O1 -c t.c
> t.c: Warning: -Warray-bounds has no effect unless compiled
> with optimization level -O2 and higher.
Yes, that warning would be good for people, if it happened once.
It's like the spiel on the airplane about how to buckle your seat belt.
It's good for everybody to hear that once. The tenth time you hear it,
it's pointless. The hundredth time, it's annoying.
Many people compile with -Werror and most people use the same set of
warning options at all optimization levels. So we would then require a
way to explicitly disable this warning.
>> Almost all current warnings already meet those requirements; the main
>> problem child is -Wuninitialized.
>
> ... and -Warray-bounds?
-Warray-bounds meets the criteria I listed, because it is pretty much
always a true positive.
I think you are basically suggesting that we drop the third criterion on
my list ("they should always be true positives"). I could support that
if others agree.
Ian
Re: GCC and out-of-range constant array indexes?
> Would it be possible to compute enough of the control flow graph > to process warnings like this one, without running the > actual optimizations, unless those optimizations are requested? > Would the cost be too high? It is possible to do it quite fast. Clang implements all warnings, including Wuninitialized, in the FE using fast analysis and they claim very low false positives. However, there are various reasons why it has not been attempted in GCC: * GCC is too slow already at -O0, slowing it down further would not be acceptable. So you need a really high-performing implementation. * The FEs are quite complex, and both C and C++ construct gimple in a different way. It would be easier to do the analysis once the FE has finished building generic/gimple. However, * The FEs fold/transform expressions as they go, so you don't have a 1-to-1 relationship between the intermediate representation generated by the FEs and the code. Yet, anything is possible in principle. First, it would need someone to do the work. As far as I know, there is no one planning or willing to work on this. And second, it would need to be accepted by the maintainers. I suggest you clarify the latter before implementing your idea, or you will be seriously disappointed. An alternative would be to move the heavier analysis to an external tool that can be invoked by the compiler and share the same infrastructure. As http://clang-analyzer.llvm.org/ does. However, GCC is many years far away to enable implementing such technology. So perhaps implementing some analysis on the FE would be a more promising approach (despite the caveats mentioned above). But you have to find out if the overhead would be acceptable for the respective maintainers. Cheers, Manuel.
Re: End of GCC 4.6 Stage 1: October 27, 2010
On Fri, 8 Oct 2010, NightStrike wrote: > On Fri, Oct 8, 2010 at 5:09 PM, Richard Guenther wrote: > > > Please also post results for the 4.5 branch. I think it doesn't make > > any sense to include a target in the list of primary or secondary > > targets if it didn't work reasonably for at least one release. > > > > Thanks, > > Richard. > > Ok. Does that have to be done regularly? Not as regularly as for trunk. But catching regressions on a branch is still important. Richard. -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: GCC and out-of-range constant array indexes?
On 08/10/2010 21:39, Gary Funck wrote: > The impact is that I may think that after I build my project at > -O0 or -O1, with various warnings enabled, that there are > potential surprises that await, when I perform a production build > at -O2 and higher. The moral of the story is that you should *test* the *production* build. Not an experimental dev build. cheers, DaveK
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 08/10/2010 19:10, NightStrike wrote: > On Fri, Oct 8, 2010 at 2:04 PM, Jonathan Wakely wrote: >> Most of the failing libstdc++ tests which shouldn't be >> platform-dependent fail with this message: >> sh: /usr/bin/stty: Bad address > > This Bad address stuff is due to some conflict with cygwin. We really > need to work with cygwin folks to find a proper fix, but are having > difficulty. > > Dave, can you work with Kai to help troubleshoot that, by any chance? I'm pretty busy at the moment, and you're the one who actually has the problem manifesting itself, plus all the log files and build dirs that you'd need to figure out what it is that's going wrong. cheers, DaveK
Re: GCC and out-of-range constant array indexes?
On Oct 8, 2010, at 18:18, Manuel López-Ibáñez wrote: > It is possible to do it quite fast. Clang implements all warnings, > including Wuninitialized, in the FE using fast analysis and they claim > very low false positives. > However, there are various reasons why it has not been attempted in GCC: > > * GCC is too slow already at -O0, slowing it down further would not be > acceptable. So you need a really high-performing implementation. The Ada front end has very extensive warnings. I don't think they really contribute measurably to performance. We don't try to construct call graphs to determine wether the array reference will be executed or not. If the line appears in your program, it will cause an error if executed, so we will warn: either you wrote dead code, or wrong code. To avoid false positives in inlined code, code instantiated from templates and the like, we have a notion of code that comes from source or not. For many warnings, we will only post the warning if the code comes from source, that is: is not generated by the compiler as part of the compilation process. -Geert
