[Bug inline-asm/42321] New: NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[Bug inline-asm/42321] New: NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[siarhei dot siamashka at gmail dot com]

Test program:
/************************/
void f()
{
    asm volatile("veor d8, d8, d8" : : :"d8","d9","d10","d11","d14","d15");
}
/************************/

$ gcc -c -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2 test.c
$ objdump -d test.o

00000000 <f>:
   0:   ed2d8b08        vpush   {d8-d11}
   4:   ed2deb04        vpush   {d14-d15}
   8:   f3088118        veor    d8, d8, d8
   c:   ecbd8b08        vpop    {d8-d11}
  10:   ecbdeb04        vpop    {d14-d15}
  14:   e12fff1e        bx      lr

The order of the last two vpop instructions is messed up.


-- 
           Summary: NEON/VFP registers from inline assembly clobber list are
                    saved/restored incorrectly
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: siarhei dot siamashka at gmail dot com
 GCC build triplet: armv4tl-softfloat-linux-gnueabi
  GCC host triplet: armv4tl-softfloat-linux-gnueabi
GCC target triplet: armv4tl-softfloat-linux-gnueabi


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[siarhei dot siamashka at gmail dot com]

------- Comment #1 from siarhei dot siamashka at gmail dot com  2009-12-07 14:42 -------
Modifying the program to list q-registers in the clobber list provides even
more interesting results:
/************************/
void f()
{
    asm volatile("veor d8, d8, d8" : : :"q4","q5","q7");
}
/************************/

$ gcc -c -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2 test.c
$ objdump -d test.o

00000000 <f>:
   0:   ed2d8b02        vpush   {d8}
   4:   ed2dab02        vpush   {d10}
   8:   ed2deb02        vpush   {d14}
   c:   f3088118        veor    d8, d8, d8
  10:   ecbd8b02        vpop    {d8}
  14:   ecbdab02        vpop    {d10}
  18:   ecbdeb02        vpop    {d14}
  1c:   e12fff1e        bx      lr

Now in addition to the mismatched save/restore order, only lower halves of
q-registers get saved.


-- 


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[ramana at gcc dot gnu dot org]

------- Comment #2 from ramana at gcc dot gnu dot org  2009-12-07 15:52 -------
Also appears with trunk as of today.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-07 15:52:27
               date|                            |


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[rearnsha at gcc dot gnu dot org]

------- Comment #3 from rearnsha at gcc dot gnu dot org  2009-12-07 15:55 -------
I can confirm both of these issues.

in asm statements GCC currently just treats 'q4' and 'd8' as aliases for s16
(which of course is just a 32-bit register); there's currently no way of
expressing that a larger entitiy is clobbered.  Of course, you won't see that
in the prologue/epilogue code because the whole D register is saved even if
just part of it has been used, but it could cause data-flow related issues
elsewhere.
in asm statements GCC currently just treats 'q4' and 'd8' as aliases for s16
(which of course is just a 32-bit register); there's currently no way of
expressing that a larger entitiy is clobbered.  Of course, you won't see that
in the prologue/epilogue code because the whole D register is saved even if
just part of it has been used, but it could cause data-flow related issues
elsewhere.


-- 


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[ramana at gcc dot gnu dot org]

------- Comment #4 from ramana at gcc dot gnu dot org  2009-12-09 16:55 -------
This occurs with arm-eabi cross as well.

Ramana


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
  GCC build triplet|armv4tl-softfloat-linux-    |armv4tl-softfloat-linux-
                   |gnueabi                     |gnueabi, x86_64-linux
   GCC host triplet|armv4tl-softfloat-linux-    |armv4tl-softfloat-linux-
                   |gnueabi                     |gnueabi, x86_64-linux
 GCC target triplet|armv4tl-softfloat-linux-    |armv4tl-softfloat-linux-
                   |gnueabi                     |gnueabi, arm-eabi
           Priority|P3                          |P2


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[ramana at gcc dot gnu dot org]

------- Comment #5 from ramana at gcc dot gnu dot org  2010-01-14 16:21 -------
I took a cursory look at this case . This looks like a bug in the
backend specifically in arm_output_epilogue where the epilogue code
isn't designed to cope for restoring disjoint sets of registers from
the stack when the frame pointer is eliminated.

The epilogue code for restoring these registers would work fine in the
case where

 a. The registers to be restored are in a single sequence for load
multiple irrespective of whether the frame pointer is used or not.

 b. If the function ends up using a frame_pointer.

We need a separate case for when the frame pointer is not required and
one has more than one sequence to restore.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
      Known to fail|                            |4.4.2 4.5.0


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[rearnsha at gcc dot gnu dot org]

------- Comment #6 from rearnsha at gcc dot gnu dot org  2010-03-21 15:58 -------
testing fix


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rearnsha at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-12-07 15:52:27         |2010-03-21 15:58:54
               date|                            |


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

[Bug inline-asm/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[rearnsha at gcc dot gnu dot org]

------- Comment #7 from rearnsha at gcc dot gnu dot org  2010-03-21 20:27 -------
Subject: Bug 42321

Author: rearnsha
Date: Sun Mar 21 20:27:00 2010
New Revision: 157609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157609
Log:
        PR target/42321
        * arm.c (arm_output_epilogue): Correctly match VFP pop instructions
        with their corresponding prologue pushes.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.c


-- 


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

[Bug target/42321] NEON/VFP registers from inline assembly clobber list are saved/restored incorrectly

[rearnsha at gcc dot gnu dot org]

------- Comment #8 from rearnsha at gcc dot gnu dot org  2010-03-21 20:30 -------
Fixed in trunk


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
          Component|inline-asm                  |target
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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