From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 350 invoked by alias); 16 Apr 2015 12:14:38 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 131027 invoked by uid 48); 16 Apr 2015 12:14:32 -0000 From: "georgmueller at gmx dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/59124] [4.8/4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" Date: Thu, 16 Apr 2015 12:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.3 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: georgmueller at gmx dot net X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg01347.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59124 Georg M=C3=BCller changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |georgmueller at gmx dot net --- Comment #12 from Georg M=C3=BCller --- 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] =3D 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=65697 --- Comment #34 from Andrew Macleod --- > 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.