[Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2

["luk32 at o2 dot pl" <gcc-bugzilla@gcc.gnu.org>]

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

Łukasz Kucharski <luk32 at o2 dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luk32 at o2 dot pl

--- Comment #5 from Łukasz Kucharski <luk32 at o2 dot pl> ---
Created attachment 33833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33833&action=edit
Example program that fails compilation with optimization enabled.
>From gcc-bugs-return-465175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 28 16:51:48 2014
Return-Path: <gcc-bugs-return-465175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30069 invoked by alias); 28 Oct 2014 16:51:47 -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 30036 invoked by uid 48); 28 Oct 2014 16:51:44 -0000
From: "nightstrike at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/63670] New: Ending C_INCLUDE_PATH with a trailing colon broken
Date: Tue, 28 Oct 2014 16:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nightstrike at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63670-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-10/txt/msg02196.txt.bz2
Content-length: 1129

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

            Bug ID: 63670
           Summary: Ending C_INCLUDE_PATH with a trailing colon broken
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nightstrike at gmail dot com

If the C_INCLUDE_PATH environment variable ends with a colon, which can happen
with typical "prepend" scripts of the form:

C_INCLUDE_PATH=/path:$C_INCLUDE_PATH

then gcc will treat every file included with <> instead of "" as being a system
header, and will not generate any warnings.  The following is a test case that
I have been using, as I got burned on a bug from not seeing the warning that
set me back several days:

a.c:
int f() {}

b.c:
#include <a.c>



Expected output:
$ gcc b.c -Wall
./a.c: In function ‘f’:
./a.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
 int f() {}
 ^


However:
$ export C_INCLUDE_PATH=:
$ gcc b.c -Wall


** No output **
>From gcc-bugs-return-465176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 28 16:55:03 2014
Return-Path: <gcc-bugs-return-465176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1890 invoked by alias); 28 Oct 2014 16:55:03 -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 1449 invoked by uid 48); 28 Oct 2014 16:54:57 -0000
From: "luk32 at o2 dot pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/62144] "Frame pointer required, but reserved" error with -fomit-frame-pointer but only with -m32 -O2
Date: Tue, 28 Oct 2014 17:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: luk32 at o2 dot pl
X-Bugzilla-Status: NEW
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-62144-4-ub4NUBm5jS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62144-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62144-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-10/txt/msg02197.txt.bz2
Content-length: 467

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

--- Comment #6 from Łukasz Kucharski <luk32 at o2 dot pl> ---
Comment on attachment 33833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33833
Example program that fails compilation with optimization enabled.

Hello, 

I believe we run into the same problem, however we extracted example that
doesn't need `-m32`. Just `-O2` breaks the build. gcc-4.8 passed with no
problems.

With regards,
luk32.
>From gcc-bugs-return-465177-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 28 17:01:50 2014
Return-Path: <gcc-bugs-return-465177-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7092 invoked by alias); 28 Oct 2014 17:01:50 -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 7039 invoked by uid 48); 28 Oct 2014 17:01:46 -0000
From: "torvald at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
Date: Tue, 28 Oct 2014 17:04: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: torvald at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-59448-4-yxsR5Yg2uX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59448-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-10/txt/msg02198.txt.bz2
Content-length: 1434

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

--- Comment #17 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #15)
> So have we concluded that we should promote memory_order_consume to
> memory_order_acquire for now?

I also think that this is the best way forward.  I believe everyone in ISO C++
SG1 agreed that this is basically a defect in the standard.

What I haven't thought through is how to deal with with carries_dependency
(7.6.4 in C++11): For GCC code generated after we promote consume to acquire,
it can safely be ignored; but should GCC code be linked to code generated by
another compiler that does not promote and expects the code to preserve
dependencies, this won't work.

I am not aware of any shipping compiler that would actually try to preserve
dependencies, and nobody else mentioned any during the discussion of this topic
in ISO C++ SG1.  Thus, we could assume that there are no such other compilers,
and make it part of the ABI (assumptions) that consume is promoted to acquire
in a correct compiler.

Alternatively, we could try to be conservative and add an acquire barrier
before the function body if any parameter of the function has
carries_dependency; and, likewise, add an acquire barrier after every call to a
function which has carries_dependency.

I don't have more input from the ISO C side, but I would guess that the
situation there is similar.

Thoughts?