[Bug tree-optimization/59124] [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

["georgmueller at gmx dot net" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

Georg Müller <georgmueller at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |georgmueller at gmx dot net

--- Comment #12 from Georg Müller <georgmueller at gmx dot net> ---
gcc --version
gcc (GCC) 5.0.1 20150413 (Red Hat 5.0.1-0.1)


When compiling the first example with -fopt-info, I see the following
difference between -O2 -funroll-loops and -O3:

gcc -Wall -Wextra -fopt-info -O2 -c 1.c -funroll-loops
1.c:11:5: note: loop turned into non-loop; it never loops.
1.c:11:5: note: loop with 6 iterations completely unrolled
1.c:10:3: note: loop turned into non-loop; it never loops.
1.c:10:3: note: loop with 5 iterations completely unrolled


gcc -Wall -Wextra -fopt-info -O3 -c 1.c -funroll-loops
1.c:11:5: note: loop turned into non-loop; it never loops.
1.c:11:5: note: loop with 7 iterations completely unrolled
1.c: In function 'foo':
1.c:12:23: warning: array subscript is above array bounds [-Warray-bounds]
       bar[j - 1] = baz[j - 1];
                       ^
1.c:12:23: warning: array subscript is above array bounds [-Warray-bounds]
1.c:10:3: note: loop turned into non-loop; it never loops.
1.c:10:3: note: loop with 5 iterations completely unrolled

So, -O2 unrolls 6 and 5 iterations, while -O3 unrolls 7 and 5.
>From gcc-bugs-return-483796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 16 12:25:33 2015
Return-Path: <gcc-bugs-return-483796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21027 invoked by alias); 16 Apr 2015 12:25:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20953 invoked by uid 48); 16 Apr 2015 12:25:29 -0000
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
Date: Thu, 16 Apr 2015 12:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mwahab at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65697-4-oKQOW6XDEp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65697-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65697-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01348.txt.bz2
Content-length: 2313

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide697

--- Comment #34 from Andrew Macleod <amacleod at redhat dot com> ---
> However, I guess some people relying on data races in their programs could
> (mis?)understand the __sync_lock_release semantics to mean that it is a
> means to get the equivalent of a C11 release *fence* -- which it is not
> because the fence would apply to the (erroneously non-atomic) store after
> the barrier, which could one lead to believe that if one observes the store
> after the barrier, the fence must also be in effect.  Thoughts?

before we get too carried away, maybe we should return to what we *think*
__sync are suppose to do. It represents a specific definition by intel.. From
the original documentation for __sync "back in the day", and all legacy uses of
sync should expect this behaviour:


"The following builtins are intended to be compatible with those described
in the "Intel Itanium Processor-specific Application Binary Interface",
section 7.4.  As such, they depart from the normal GCC practice of using
the ``__builtin_'' prefix, and further that they are overloaded such that
they work on multiple types."

The definition of "barrier" from that documentation is :

acquire barrier : Disallows the movement of memory references to visible data
from before the intrinsic (in program order) to after the intrinsic (this
behavior is desirable at lock-release operations, hence the name).

release barrier: Disallows the movement of memory references to visible data
from after the intrinsic (in program order) to before the intrinsic (this
behavior is desirable at lock-acquire operations, hence the name).

full barrier: disallows the movement of memory references to visible data past
the intrinsic (in either direction), and is thus both an acquire and a release
barrier. A barrier only restricts the movement of memory references to visible
data across the intrinsic operation: between synchronization operations (or in
their absence), memory references to visible data may be freely reordered
subject to the usual data-dependence constraints.

Caution: Conditional execution of a synchronization intrinsic (such as within
an if or a while statement) does not prevent the movement of memory references
to visible data past the overall if or while construct.