🚀 go-pugleaf

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-01-24 21:17:15 UTC ---
    if ( i>=SIZE && f1() )
        throw 1;
    bool v[SIZE] = { 1, 1 };
    return v[i];


If f1 returns false, then you have above array bounds access.

>because constructor of struct A never called with "bad"
How can that be true if the compiler does not know that or could figure that
out?

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-01-24 21:40:12 UTC ---
I didn't really follow in detail what we have been doing about these warnings,
but submitter may have a point that the warning should not say "is above", and
instead say something like "may be above". Manuel what do you think?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-01-24 22:21:26 UTC ---
(In reply to comment #2)
> I didn't really follow in detail what we have been doing about these warnings,
> but submitter may have a point that the warning should not say "is above", and
> instead say something like "may be above". Manuel what do you think?

I think these warnings are exactly like uninitialized warnings. GCC can
sometimes prove that it happens but most of the time it can only be proved that
it "may" happen. Contrary to Wuninitialized, I am not sure that GCC analysis in
this warning is powerful enough to try to detect this difference, so I would
say, yes, using "may be" should be more appropriate.

But I think you better ask the corresponding maintainers, they are the ones
that will decide.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-25 10:57:27 UTC ---
Well.  You might argue that the wording should be 'may be' in all cases
where the offending statement might not be executed (which is certainly
undecidable as you can't know whether the function is executed at all).
But it also isn't the way we handle other warnings (in particular the
uninitialized variable uses).

Thus I think we should not fix this bug (and it is a non-bug, as certainly
the code in question isn't obviously dead).

Interprocedual analysis could see that we call the function with a boolean
value (thus, either 0 or 1).

That said - we can't suit everyone with this kind of warnings.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-01-25 12:58:12 UTC ---
(In reply to comment #4)
> Well.  You might argue that the wording should be 'may be' in all cases
> where the offending statement might not be executed (which is certainly
> undecidable as you can't know whether the function is executed at all).
> But it also isn't the way we handle other warnings (in particular the
> uninitialized variable uses).

This is strange. We *precisely* says "is uninitialized" when it can be proved
that it happens and "may be uninitialized" when it is just some code-paths or
we cannot prove that it doesn't happen. And we certainly (or used to, I haven't
been following these bugs lately) classify as bugs when the wrong message is
printed.

> Thus I think we should not fix this bug (and it is a non-bug, as certainly
> the code in question isn't obviously dead).
> 
> Interprocedual analysis could see that we call the function with a boolean
> value (thus, either 0 or 1).
> 
> That said - we can't suit everyone with this kind of warnings.

Then I guess we should just point out people to static analysis tools, like
http://clang-analyzer.llvm.org/, which are more suited for this task than GCC.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-01-25 13:07:06 UTC ---
If you want to, although Clang can't analyze C++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47444

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-01-25 13:16:55 UTC ---
(In reply to comment #6)
> If you want to, although Clang can't analyze C++

The difference is that by design, Clang aims to do it at some moment in the
future, it is a matter of time, resources and contributors, whereas by design
GCC aims to not do it.

I see a lot of frustrated users trying to use GCC for what it is not meant to
be used and getting their bugs closed as invalid.

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

--- Comment #8 from eidletni at mail dot ru 2011-01-25 18:46:50 UTC ---
(In reply to comment #1)
> >because constructor of struct A never called with "bad"
> How can that be true if the compiler does not know that or could figure that
> out?

In this case I'm expecting nothing.

So, if compiler is smart enough to say 'may be above', why in this simple code
I see no warning:

bool f(unsigned i)
{
    bool v[2] = { 1, 1 };
    return v[i];
}

?

and if we continue, in this code, which EXACTLY have array overflow, I see no
warning:

bool f(unsigned i)
{
    bool v[2] = { 1, 1 };
    return v[i];
}

void g() { f(1000); }

(In reply to comment #1)
>     if ( i>=SIZE && f1() )
>         throw 1;
>     bool v[SIZE] = { 1, 1 };
>     return v[i];
>
>
> If f1 returns false, then you have above array bounds access.

I repeat, if I REMOVE this code "if ( i>=SIZE && f1() )", which is equal to f1
function return false, warning message disappears!

(In reply to comment #0)
> Warning disappears if:
> *) remove f1() call in "if ( i>=SIZE && f1() )"
> *) make "return true" instead of "throw 1"
> *) inline struct A constructor, "inline A::A(unsigned i)"
> *) make size of array "bool v[]" equal 1, "enum { SIZE = 1 }"

I really don't understand, why you guys so easily set wontfix to this bug.
Nobody cares that "inlining constructor" or "return instead throw" depends on
printing warning message?

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-01-25 19:10:42 UTC ---
(In reply to comment #8)
> I really don't understand, why you guys so easily set wontfix to this bug.
> Nobody cares that "inlining constructor" or "return instead throw" depends on
> printing warning message?

WONTFIX doesn't mean "nobody cares"

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG444

--- Comment #10 from eidletni at mail dot ru 2011-01-25 19:40:17 UTC ---
(In reply to comment #9)
> WONTFIX doesn't mean "nobody cares"

As I know, it does. Bugzilla resolution: fixed - "we have problem and fix it",
invalid - "user may think that we have problem, but we don't", wontfix - "we
have problem, but we don't care"...

http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Warning-Options.html#Warning-Options

-Warray-bounds
    This option is only active when -ftree-vrp is active (default for -O2 and
above). It warns about subscripts to arrays that are always out of bounds. This
warning is enabled by -Wall.

I don't see any "may be" words.

Let's make it clear. I do not tell you to fix this tomorrow or set importance
of bug to critical, i just saying that it will be nice to fix this someday and
make compiler better.

With best wishes.