[Bug regression/59086] New: error: ‘asm’ operand has impossible constraints

[Bug regression/59086] New: error: ‘asm’ operand has impossible constraints

[aivchenk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

            Bug ID: 59086
           Summary: error: ‘asm’ operand has impossible constraints
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aivchenk at gmail dot com

Android image build with trunk gcc failed after the following commit:

Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Oct 3 17:25:42 2013 +0000

        * i386.c (ix86_option_override_internal): Do not enable
        accumulate-outgoing-args when producing unwind info.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@203171
138bc75d-0d04-0410-961f-82ee72b054a4

==================

The reduced testcase looks something like this
(previous r203169 is able to compile it):

#include <emmintrin.h>

void testFunc(int count) {

  int x;
  __m128i tmp1;
  __asm__(
                  "1:\n"
                  :"+d"(x)
                  :[count] "m" (count), [tmp1] "m" (tmp1)
                  :"ecx","esi","edi","eax"
          );
}

The compiling options:
gcc test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
>From gcc-bugs-return-434345-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 12 11:19:10 2013
Return-Path: <gcc-bugs-return-434345-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30283 invoked by alias); 12 Nov 2013 11:19:08 -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 30209 invoked by uid 48); 12 Nov 2013 11:19:04 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/29143] address-of overloaded function does not work in function call
Date: Tue, 12 Nov 2013 11:19: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.1.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to target_milestone
Message-ID: <bug-29143-4-ICjrZyGiQq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-29143-4@http.gcc.gnu.org/bugzilla/>
References: <bug-29143-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: 2013-11/txt/msg01122.txt.bz2
Content-length: 522

http://gcc.gnu.org/bugzilla/show_bug.cgi?id)143

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com
   Target Milestone|---                         |4.9.0

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Mine.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i?86-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-14
          Component|regression                  |rtl-optimization
   Target Milestone|---                         |4.9.0
            Summary|error: ‘asm’ operand has    |[4.9 Regression] error:
                   |impossible constraints      |‘asm’ operand has
                   |                            |impossible constraints
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
>From gcc-bugs-return-434559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 14 08:56:19 2013
Return-Path: <gcc-bugs-return-434559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13951 invoked by alias); 14 Nov 2013 08:56:19 -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 13898 invoked by uid 48); 14 Nov 2013 08:56:16 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59085] internal compiler error: Segmentation fault
Date: Thu, 14 Nov 2013 08:56: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.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: bug_status cf_reconfirmed_on everconfirmed cf_known_to_fail
Message-ID: <bug-59085-4-ps7kShRnMW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59085-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59085-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: 2013-11/txt/msg01336.txt.bz2
Content-length: 600

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY085

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-14
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2, 4.9.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on x86_64 with -m32 and -fpermissive.  Trying to reduce.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
First of all, reload also cannot generate this code with mentioned i386.c
change

When we use -maccumulate-outgoing-args, we have before reload/LRA

(insn 6 10 7 2 (parallel [
            (set (reg:SI 87 [ x ])
                (asm_operands:SI ("1:
") ("=d") 0 [
                        (mem/c:SI (reg/f:SI 16 argp) [0 count+0 S4 A32])
                        (mem/c:V2DI (plus:SI (reg/f:SI 20 frame)
                                (const_int -32 [0xffffffffffffffe0])) [0 tmp1+0
S16 A128])
                        (reg:SI 87 [ x ])
                    ]
                     [
                        (asm_input:SI ("m") (null):0)
                        (asm_input:V2DI ("m") (null):0)
                        (asm_input:SI ("0") (null):0)
                    ]
                     [] b2.c:7))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
            (clobber (reg:QI 0 ax))
            (clobber (reg:QI 5 di))
            (clobber (reg:QI 4 si))
            (clobber (reg:QI 2 cx))
        ]) b2.c:7 -1

and argp is transformed after lra/reload into fp+const:

(insn 6 10 7 2 (parallel [
            (set (reg:SI 1 dx [orig:87 x ] [87])
                (asm_operands:SI ("1:
") ("=d") 0 [
                        (mem/c:SI (plus:SI (reg/f:SI 6 bp)
                                (const_int 8 [0x8])) [0 count+0 S4 A32])
                        (mem/c:V2DI (reg/f:SI 7 sp) [0 tmp1+0 S16 A128])
                        (reg:SI 1 dx [orig:87 x ] [87])
                    ]
 If we don't use -maccumulate-outgoing-args, we have before reload/LRA:

(insn/f 10 3 2 2 (set (reg:SI 89)
        (reg:SI 2 cx)) 86 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 2 cx)
        (expr_list:REG_CFA_SET_VDRAP (reg:SI 89)
            (nil))))
...
(insn 6 11 7 2 (parallel [
            (set (reg:SI 87 [ x ])
                (asm_operands:SI ("1:
") ("=d") 0 [
                        (mem/c:SI (reg:SI 89) [0 count+0 S4 A32])
                        (mem/c:V2DI (plus:SI (reg/f:SI 20 frame)
                                (const_int -32 [0xffffffffffffffe0])) [0 tmp1+0
S16 A128])
                        (reg:SI 87 [ x ])
                    ]
As we have only 1 free reg for asm (4 regs are clobbered in the asm, ebx is
taken for -fPIC, ebp is always needed for -mstackrealign), we cannot use it for
p87 (it has + constraint) and p89.  The generated code also has no equiv for
p89 to use it.  So reload/LRA can do nothing in this situation.

Even if i implement fp elimination in presence of sp changes in RTL (and i am
working on it as it is needed for other existing PRs and very important for
generated code performance), bp will not be free (again because of
-mstackrealign).  So if we want to compile the code, we should revert the
original change

-  /* ??? Unwind info is not correct around the CFG unless either a frame
-     pointer is present or M_A_O_A is set.  Fixing this requires rewriting
-     unwind info generation to be aware of the CFG and propagating states
-     around edges.  */
-  if ((flag_unwind_tables || flag_asynchronous_unwind_tables
-       || flag_exceptions || flag_non_call_exceptions)
-      && flag_omit_frame_pointer
-      && !(target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
-    {
-      if (target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS)
-       warning (0, "unwind tables currently require either a frame pointer "
-                "or %saccumulate-outgoing-args%s for correctness",
-                prefix, suffix);
-      target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
-    }
-

although we could modify the comment if it is not true anymore.

Still the code will be broken for some tunings with -mno-accumulate-args by
default.

To really solve the problem, we should free bp somehow.  Probably it can be
done by smarter stack realign implementation or saving/restoring bp around asm.
 The later is very complicated task and can not be done in gcc-4.9 time frame.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We never really allowed asm statements to use nearly all available registers,
so I would declare this to be bug in android's asm statement...
Though for sure it would be better to free EBP somehow.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[aivchenk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #5 from Alexander Ivchenko <aivchenk at gmail dot com> ---
I understand the technical reasons of the complexity of the correct and
efficient register allocation here, but what I don't understand is this:

$> gcc_4.7 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
$> gcc_4.8 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
$> gcc_4.9 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
test.c: In function 'testFunc':
test.c:7:3: error: 'asm' operand has impossible constraints
   __asm__(
   ^

How can we allow to break the user code with the release version of the
compiler here..?

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Alexander Ivchenko from comment #5)
> I understand the technical reasons of the complexity of the correct and
> efficient register allocation here, but what I don't understand is this:
> 
> $> gcc_4.7 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> $> gcc_4.8 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> $> gcc_4.9 test.c -c -fPIC -mstackrealign -march=core-avx2 -m32
> test.c: In function 'testFunc':
> test.c:7:3: error: 'asm' operand has impossible constraints
>    __asm__(
>    ^
> 
> How can we allow to break the user code with the release version of the
> compiler here..?

If it does something wrong, and using almost all or all available registers in
an asm is always wrong, then why not.  Just compile it with
-maccumulate-outgoing-args or without -mstackrealign or better rework either to
need fewer registers (pass some more arguments in memory or even better some
memory structure, so that they can all be loaded/saved from there using fewer
registers).

I'd say this should be closed NOTABUG (or WONTFIX?).

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[aivchenk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #7 from Alexander Ivchenko <aivchenk at gmail dot com> ---
Do we have any documentation that states how many registers can be used in
inline assembler for a particular arch and optset? "almost all" is not good
enough for that.

If the user code that worked in 4.8 correctly is now broken for 4.9, we better
need to respect the user and document it properly.

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> ---
> Do we have any documentation that states how many registers can be used in
> inline assembler for a particular arch and optset? "almost all" is not good
> enough for that.

It is somewhat difficult question.  Basically you are not supposed to use any
"fixed"
registers where fixed set of registers depends on compilation flags. For
example ESP is
always fixed, EBP is fixed depending on frame pointer elimination.
With PIC you need also EBP for GOT pointer and for DRAP you need another
register.
You need to leave enough registers so reload can load all additional operand
and addresses.
Things may have also changes with IRA - last time I looked into this was with
old reload.

Vladimir, do you have idea about more precise description?
> 
> If the user code that worked in 4.8 correctly is now broken for 4.9, we better
> need to respect the user and document it properly.

Well, the problem is that precise set of constraints is exremely tied to
compiler internals (and it also changes from release to release, indeed).  It
is overall problem of ASM statement extension in GCC, sadly.

Honza

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[vmakarov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

--- Comment #9 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #8)
> > Do we have any documentation that states how many registers can be used in
> > inline assembler for a particular arch and optset? "almost all" is not good
> > enough for that.
> 
> It is somewhat difficult question.  Basically you are not supposed to use
> any "fixed"
> registers where fixed set of registers depends on compilation flags. For
> example ESP is
> always fixed, EBP is fixed depending on frame pointer elimination.
> With PIC you need also EBP for GOT pointer and for DRAP you need another
> register.
> You need to leave enough registers so reload can load all additional operand
> and addresses.
> Things may have also changes with IRA - last time I looked into this was
> with old reload.
> 
> Vladimir, do you have idea about more precise description?

It is very difficult to formulate this for all cases.

For one alternative, I would say for any given class the number of allocatable
hard regs of given class should be not less than max (non-output operands with
a constraint register class intersecting given class, analogous for non-input
operands).  Early clobber operands are considered non-input and non-output. 
Operand modes should be taken into account too, e.g. an operand needs 2 regs.

We cannot assume that a pseudo has an equivalent unallocatable hard reg
expression.

Still this description might not work when we have a subreg of bigger pseudo
requiring at least 2 hard regs as sometimes we need to reload all pseudo.

Also this formulation can be too strict when there are register and
non-register constraint, e.g. memory.  Several alternative can complicate the
situation even more.

As algorithms behind reload/LRA are too complicated and has a lot of details,
the formulation will be too long.  The simple formulation for all possible
cases would be too constrained and not practical.  Therefore nobody tried to
write it down and we just have a fatal message 'can not reload'.


> > 
> > If the user code that worked in 4.8 correctly is now broken for 4.9, we better
> > need to respect the user and document it properly.
> 
> Well, the problem is that precise set of constraints is exremely tied to
> compiler internals (and it also changes from release to release, indeed).  It
> is overall problem of ASM statement extension in GCC, sadly.
> 
>

[Bug rtl-optimization/59086] [4.9 Regression] error: ‘asm’ operand has impossible constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59086

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, closing.