* [Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
2014-05-20 6:00 [Bug middle-end/61243] New: [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65 Joost.VandeVondele at mat dot ethz.ch
@ 2014-05-20 6:41 ` ubizjak at gmail dot com
2014-05-20 16:41 ` rsandifo at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: ubizjak at gmail dot com @ 2014-05-20 6:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
The same failure is triggered with profiledbootstrap build. First recorded
bootstrap failure is at r210603 [1]. Last good bootstrap is at r210599 [2].
It looks that r210603 is problematic [3]. Author CC'd.
[1] https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00224.html
[2] https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01581.html
[3] https://gcc.gnu.org/ml/gcc-cvs/2014-05/msg00646.html
>From gcc-bugs-return-451990-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 20 06:41:55 2014
Return-Path: <gcc-bugs-return-451990-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21122 invoked by alias); 20 May 2014 06:41:55 -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 21070 invoked by uid 48); 20 May 2014 06:41:52 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65
Date: Tue, 20 May 2014 06:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on target_milestone everconfirmed
Message-ID: <bug-61243-4-gcZMPpcOv7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61243-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61243-4@http.gcc.gnu.org/bugzilla/>
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: 2014-05/txt/msg01682.txt.bz2
Content-length: 540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-05-20
Target Milestone|--- |4.10.0
Ever confirmed|0 |1
--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Confirmed.
>From gcc-bugs-return-451991-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 20 06:59:24 2014
Return-Path: <gcc-bugs-return-451991-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3973 invoked by alias); 20 May 2014 06:59:24 -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 3919 invoked by uid 48); 20 May 2014 06:59:19 -0000
From: "muks at banu dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61236] GCC 4.9 generates incorrect object code
Date: Tue, 20 May 2014 06:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: muks at banu dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61236-4-NFey4C5hlR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61236-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61236-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: 2014-05/txt/msg01683.txt.bz2
Content-length: 2183
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida236
--- Comment #9 from Mukund Sivaraman <muks at banu dot com> ---
Hi Jakub, Markus
We discussed this during our daily standup call today, and there are two
points we'd like to make:
1. The qsort() defintion in C99 doesn't explicitly state that base must
not be NULL, though it seems you are deducing that from "the initial
element of which is pointed to by base."
The POSIX definition of qsort() adds this:
"If the nel argument has the value zero, the comparison function
pointed to by compar shall not be called and no rearrangement shall
take place."
2. From our perpective as users of GCC, this kind of agressive
optimization seems counter-intuitive. We'd like code to compile to
correct object code first before performance.
When the compiler knows at that point that base (=x) is NULL as an
argument to qsort(), why isn't it warning when the attribute expects it
to be non-NULL, esp. as it is using this inferred decision to optimize
code down below?
The compiler knows x is NULL at this point in this codepath regardless
of what qsort()'s attributes say. Why is it using the attribute then?
qsort() also does not assert (at runtime) that base is non-NULL. There
is no way to detect this for code which used to run correctly before,
but doesn't anymore (without it _hopefully_ crashing somewhere).
Other similar functions such as memcpy(), etc. also have this annotation
in glibc, whereas there is no definition of n=0 case in C99.
This example of qsort() is in libc, but imagine a case where a program
uses a 3rd party system installed utility shared library. If the
library, in a new version, adds a nonnull annotation for a function, but
the library function itself continues to work for NULL input, see what
happens to the program: The library is not affected, but the pointer in
the calling program is affected if the compiler infers that the pointer
is non-NULL due to the attribute. The calling program is now buggy due
to a change in the library. How do we discover it?
It makes sense to just avoid the qsort() in our case and we will update
our code to do so, but please consider the arguments above.
^ permalink raw reply [flat|nested] 6+ messages in thread