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

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

[brooks at gcc dot gnu.org]

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

            Bug ID: 62144
           Summary: "Frame pointer required, but reserved" error with
                    -fomit-frame-pointer but only with -m32 -O2
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: brooks at gcc dot gnu.org

Created attachment 33328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33328&action=edit
(Example program)

The following error is unexpected.  We use -fomit-frame-pointer to allow us to
reserve a register, but apparently it is required anyway -- but only when
optimization is turned to -O2 and when compiled at -m32.

$ cat t.i
register int x0 asm ("bp");
static char x1[4096];
int strlen (char *);
void x2 ();
void
x3 ()
{
    switch (0)
    case 0:
    x2 (0);
    int x4 = strlen (x1);
    if (x1[x4] == '\n')
        x2 ();
}
$ gcc-archive/trunk/213772/bin/gcc -c t.i -m32 -fomit-frame-pointer
$ gcc-archive/trunk/213772/bin/gcc -c t.i -O1 -m32 -fomit-frame-pointer
$ gcc-archive/trunk/213772/bin/gcc -c t.i -O2 -m32 -fomit-frame-pointer
t.i: In function ‘x3’:
t.i:6:1: error: frame pointer required, but reserved
 x3 ()
 ^
t.i:1:14: note: for ‘x0’
 register int x0 asm ("bp");
              ^
$


Although the examples above use trunk, this also occurs with the 4.9 branch at
the same revision.
>From gcc-bugs-return-458496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 14 18:51:38 2014
Return-Path: <gcc-bugs-return-458496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6772 invoked by alias); 14 Aug 2014 18:51:38 -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 6722 invoked by uid 48); 14 Aug 2014 18:51:34 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
Date: Thu, 14 Aug 2014 18:51: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62091-4-3XHNGhpXmC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62091-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62091-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-08/txt/msg00993.txt.bz2
Content-length: 1891

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I added the comment to wrong PR so I am moving it here:

Hi,
There are two issues seen with the testcase.  First is that ipa-devirt misses
the ctor call that can be easily fixed by:
Index: ipa-devirt.c
==================================================================--- ipa-devirt.c        (revision 213969)
+++ ipa-devirt.c        (working copy)
@@ -2663,6 +2663,8 @@
                          * BITS_PER_UNIT;
                op = TREE_OPERAND (op, 0);
              }
+           else if (DECL_P (op))
+             ;
            else
              {
                 tci->speculative = true;

I am testing this patch.

However even with this change we won't devirtualize because we believe that we
can not reffer to the virtual method.
The node is:
(gdb) p snode->dump (stderr)
_ZNK1A5m_fn1Ev/3 (virtual SnmpSyntax* A::m_fn1() const) @0x7ffff6dad8a0
  Type: function definition analyzed
  Visibility: external public weak comdat comdat_group:_ZNK1A5m_fn1Ev one_only
virtual
  Address is taken.
  References:
  Referring: _ZTV1A/12 (addr)
  Availability: available
  First run: 0
  Function flags: body
  Called by:
  Calls:

I wonder what we should do with both external and comdat here.  Jason, can we
devirtualize?
The constructor is keyed to other compilation unit here, but we are provided
with a body
that we will never use (modulo the tree-ssa-pre bug that brings the reference
into code).

I can imagine implementing logic to make us to devirtualize only when inlining
and never introduce
direct refernece otherwise, but it would be quite work - so far we always need
the intermediate
reference before inlining. (Basically we will need to make ipa-devirt to
produce direct call and
revert if inliner fails to inline the function at the end of IPA queue).

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-15
                 CC|                            |vmakarov at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
frame_pointer_needed is set by setup_can_eliminate.  Which means that desipte
-fomit-frame-pointer IRA is not able to eliminate the frame pointer?

Vlad?

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

[brooks at gcc dot gnu.org]

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

--- Comment #2 from Brooks Moses <brooks at gcc dot gnu.org> ---
Ping?  Any updates on this?

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Brooks Moses from comment #2)
> Ping?  Any updates on this?

Sorry, I'll look at this in a week or if I am lucky this week.  Right now, I am
quite busy with register rematerialization pass in LRA which I'd like to make
ready for gcc-5.0.

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

[brooks at gcc dot gnu.org]

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

--- Comment #4 from Brooks Moses <brooks at gcc dot gnu.org> ---
Thanks.  I have to admit that that does seem more generally useful!  :)

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

[luk32 at o2 dot pl]

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?

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd note that -fomit-frame-pointer is never a guarantee that frame pointer will
be omitted, there are still tons of cases where it can't be omitted, VLAs,
alloca, various specialized builtins, etc.

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

[luk32 at o2 dot pl]

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

--- Comment #8 from Łukasz Kucharski <luk32 at o2 dot pl> ---
Jakub,

fair enough. However, changing the optimization level should not break the
compilation. The issue is, at least for me, is not that we can't omit the frame
pointer, but that it depends on the optimization level.

I couldn't find anything in the docs, which would allow such behaviour. Maybe I
missed it. Anyway, IMO at most a warning should be issued that a potential
optimization conflicts with the flag.

With regards,
luk32.
>From gcc-bugs-return-465208-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 29 09:46:02 2014
Return-Path: <gcc-bugs-return-465208-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14830 invoked by alias); 29 Oct 2014 09:46:02 -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 14785 invoked by uid 48); 29 Oct 2014 09:45:56 -0000
From: "jakub at gcc dot gnu.org" <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: Wed, 29 Oct 2014 10: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: jakub 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-62144-4-ApLZlosAdv@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: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg02229.txt.bz2
Content-length: 607

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The documentation on -fomit-frame-pointer says: "Don't keep the frame pointer
in a register for functions that don't need one."
where whether soemthing needs a frame pointer or not is not precisely defined
(exactly because the actual check in the compiler whether something needs a
frame pointer or not is not really something simple, and depends on many
things).
Whether we can avoid frame pointer on this exact testcase is something Vlad can
perhaps look at, my answer was just general.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-* i?86-*-*
          Component|inline-asm                  |target
           Keywords|                            |diagnostic

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In the case of comment #6, it is the expansion of memmove and memset which
causes the requirement of a frame pointer but I have not looked into why.

Really global registers were a mistake ...