Uma shankar <shankar...@gmail.com> writes:
> a) The compiler activates the warning mechanism only if optimisation
> is enabled at compilation time with -O option. For all the bugs that
> I went through at bugzilla, the failure is not -O level dependent.
> The warning-failure occurs for all levels of optimisation. So, I
> believe this is the general case.
>
> But then I came across the following failure case.
>
> ////////////////////
> #include <stdio.h>
> int Check(int *a)
> {
> if (*a == 0)
> {
> printf("This is sample \n");
> }
> return *a;
> }
> int main()
> {
> int call;
> Check(&call);
> return 0;
> }
> /////////////////////
>
> This one fails to warn when compiled with any level below 3.
> With -O3, gcc is able to warn.
>
> Can someone tell me which is the corresponding bug logged at bugzilla ?
>
> Are there any more such bugs which disappear when compiled with
> specific -O level ?
>
> b) Are there any known "fail to do uninitialised-warning" gcc bugs
> which are language-dependent ? I mean bugs which occur only in C++ ,
> but not in C. ( Bugs which arise out of C++ language features/syntax. ) .
> If so, I would like to know.
>
> Elsewhere, someone pointed out to me that these are not "bugs", but occur
> due to tradeoff in compiler against false positive warnings. I am
> referring them
> as "bugs" only because compiler hackers do so.
This message is also not appropriate for gcc@gcc.gnu.org, but is
appropriate for gcc-h...@gcc.gnu.org.
gcc is known to be inconsistent about when it issues warnings about
uninitialized variables. This is not a good thing. It is a
consequence of the fact that gcc issues those warnings based on the
implementation of different optimizations.
I'm not aware of any attempts to characterize precisely when gcc warns
and when it does not. Any such characterization would have to be
updated for each new release in any case.
Ian
