[Bug c/48597] New: x86-64 unwind register save location misses half-register write?

[Bug c/48597] New: x86-64 unwind register save location misses half-register write?

[lat at cern dot ch]

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

           Summary: x86-64 unwind register save location misses
                    half-register write?
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: lat@cern.ch


On RHEL6 x86-64, GCC compiled libm has inaccurate unwind info for
__ieee754_rem_pio2f() as called by tanf(). The problem is GCC knows %rbp is
saved, and correctly describes the save location, but delays emitting the info
from actual register save to a later address, missing write to half-size
register alias %ebp in between. If unwinding starts in the in-between region,
%rbp is not restored correctly off the stack, leading to problems later in a
stack frame with CFA defined as offset off %rbp.

The start of assembly and unwind info for __ieee754_rem_pio2f follows.

Dump of assembler code for function __ieee754_rem_pio2f:
  0x00007ffff35b1080 <+0>:  push   %rbp
  0x00007ffff35b1081 <+1>:  movd   %xmm0,%ebp
  0x00007ffff35b1085 <+5>:  push   %rbx
  0x00007ffff35b1086 <+6>:  mov    %ebp,%ecx
  0x00007ffff35b1088 <+8>:  mov    %rdi,%rbx
  0x00007ffff35b108b <+11>: and    $0x7fffffff,%ecx
  0x00007ffff35b1091 <+17>: sub    $0x18,%rsp

00001d30 0000003c 00001d34 FDE cie=00000000 pc=0002c080..0002c3ba
  DW_CFA_advance_loc: 1 to 0002c081
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 5 to 0002c086
  DW_CFA_def_cfa_offset: 24
  DW_CFA_advance_loc: 5 to 0002c08b
  DW_CFA_offset: r3 (rbx) at cfa-24
  DW_CFA_offset: r6 (rbp) at cfa-16

As you can see at 0x2c081 / 0x00007ffff35b1081 a "movd %xmm0, %ebp" instruction
writes to %rbp, but the unwind info describes the save location for the
register only at 0x2c08b / 0x00007ffff35b108b.

It's easiest to demo the effect in GDB; the original problem occurred in a
sampling profiler which uses libunwind. See (1) for the full GDB session trace.
To replicate this, you need a) a call to tanf() with an argument requiring
__ieee754_rem_pio2f() call, b) a function above tanf() with CFA based on %rbp
(SimpleNavigableLayer::wellInside() in (1)), and c) a stack walk within the
three instructions with inaccurate unwind info.

RHEL6 glibc seems to be built with GCC 4.4.4 (2). The entire libm has just four
instances of 'movd %xmmN,%ebp', in __ieee754_asinf, __ieee754_j1f,
__ieee754_lgammaf_r, __ieee754_rem_pio2f; all with the same unwind info issue.
In GLIBC 2.13 compiled with GCC 4.6.x pre-release (3), the first three still
have a 'vmovd %xmmN,%ebp', plus there's one in cprojf, but none in
__ieee754_rem_pio2f. Of these only __ieee754_lgammaf_r is incorrect (4), all
others have correct unwind info - though I am not sure if they are just
'different' rather than 'fixed', see how __ieee754_rem_pio2f changed in (5).

If there is easy enough a fix, we have some interest in back-port to 4.4.x in
case we have any luck convincing RHEL to pick up the patch and rebuild
libc/libm.

(1)

$ gdb --args cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun...(no
debugging symbols found)...done.
(gdb) b __ieee754_rem_pio2f
Function "__ieee754_rem_pio2f" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__ieee754_rem_pio2f) pending.
(gdb) b 'SimpleNavigableLayer::wellInside(FreeTrajectoryState const&,
PropagationDirection, ForwardDetLayer const*, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const' 
Function "SimpleNavigableLayer::wellInside(FreeTrajectoryState const&,
PropagationDirection, ForwardDetLayer const*, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 ('SimpleNavigableLayer::wellInside(FreeTrajectoryState const&,
PropagationDirection, ForwardDetLayer const*, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const') pending.
(gdb) disa 1
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>ena 1
>cont
>end
(gdb) r
Starting program: /data/CMSSW_4_2_0_pre6/bin/slc5_amd64_gcc451/cmsRun
/home/data/runPU/TTbar_Tauola_RAW2DIGI_L1Reco_RECO_PU_lto5.py
[Thread debugging using libthread_db enabled]
14-Apr-2011 01:22:27 CEST  Initiating request to open file
file:0E1B7BC9-7E2C-E011-A37B-0018F3D096B6.root
14-Apr-2011 01:22:29 CEST  Successfully opened file
file:0E1B7BC9-7E2C-E011-A37B-0018F3D096B6.root
Begin processing the 1st record. Run 1, Event 1401, LumiSection 666694 at
14-Apr-2011 01:22:43.145 CEST
%MSG-w SiStripQuality:  SiStripZeroSuppression:siStripZeroSuppression 
14-Apr-2011 01:22:45 CEST Run: 1 Event: 1401
The cabling should always include the active feds in runInfo and possibly have
some morethere are instead 59 feds only active in runInfo
%MSG

Breakpoint 2, 0x00007fffe9e00414 in
SimpleNavigableLayer::wellInside(FreeTrajectoryState const&,
PropagationDirection, ForwardDetLayer const*, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so

Breakpoint 1, 0x00007ffff37c5080 in __ieee754_rem_pio2f () from
/lib64/libm.so.6(gdb) x/i $pc
=> 0x7ffff37c5080 <__ieee754_rem_pio2f>:    push   %rbp
(gdb) bt 10
#0  0x00007ffff37c5080 in __ieee754_rem_pio2f () from /lib64/libm.so.6
#1  0x00007ffff37c836a in tanf () from /lib64/libm.so.6
#2  0x00007fffe9e00ef5 in SimpleNavigableLayer::wellInside(FreeTrajectoryState
const&, PropagationDirection, BarrelDetLayer const*, std::vector<DetLayer
const*, std::allocator<DetLayer const*> >&) const () from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#3  0x00007fffe9e10257 in SimpleNavigableLayer::wellInside(FreeTrajectoryState
const&, PropagationDirection, std::vector<DetLayer const*,
std::allocator<DetLayer const*> > const&, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#4  0x00007fffe9dfe78a in
SimpleBarrelNavigableLayer::nextLayers(FreeTrajectoryState const&,
PropagationDirection) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#5  0x00007fffe76ccf9c in DetLayer::nextLayers(FreeTrajectoryState const&,
PropagationDirection) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libTrackingToolsDetLayers.so
#6  0x00007fffea4d373f in
BaseCkfTrajectoryBuilder::findStateAndLayers(TempTrajectory const&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#7  0x00007fffea4eaab2 in
GroupedCkfTrajectoryBuilder::advanceOneLayer(TempTrajectory&, TrajectoryFilter
const*, Propagator const*, bool, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#8  0x00007fffea4e7f8c in
GroupedCkfTrajectoryBuilder::groupedLimitedCandidates(TempTrajectory&,
TrajectoryFilter const*, Propagator const*, bool, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#9  0x00007fffea4e90b1 in GroupedCkfTrajectoryBuilder::buildTrajectories ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
(More stack frames follow...)

(gdb) si 2
0x00007ffff37c5085 in __ieee754_rem_pio2f () from /lib64/libm.so.6
(gdb) x/i $pc
=> 0x7ffff37c5085 <__ieee754_rem_pio2f+5>:    push   %rbx
(gdb) bt 10
#0  0x00007ffff37c5085 in __ieee754_rem_pio2f () from /lib64/libm.so.6
#1  0x00007ffff37c836a in tanf () from /lib64/libm.so.6
#2  0x00007fffe9e00ef5 in SimpleNavigableLayer::wellInside(FreeTrajectoryState
const&, PropagationDirection, BarrelDetLayer const*, std::vector<DetLayer
const*, std::allocator<DetLayer const*> >&) const () from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

(gdb) si 3
0x00007ffff37c508b in __ieee754_rem_pio2f () from /lib64/libm.so.6
(gdb) x/i $pc
=> 0x7ffff37c508b <__ieee754_rem_pio2f+11>:    and    $0x7fffffff,%ecx
(gdb) bt 10
#0  0x00007ffff37c508b in __ieee754_rem_pio2f () from /lib64/libm.so.6
#1  0x00007ffff37c836a in tanf () from /lib64/libm.so.6
#2  0x00007fffe9e00ef5 in SimpleNavigableLayer::wellInside(FreeTrajectoryState
const&, PropagationDirection, BarrelDetLayer const*, std::vector<DetLayer
const*, std::allocator<DetLayer const*> >&) const () from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#3  0x00007fffe9e10257 in SimpleNavigableLayer::wellInside(FreeTrajectoryState
const&, PropagationDirection, std::vector<DetLayer const*,
std::allocator<DetLayer const*> > const&, std::vector<DetLayer const*,
std::allocator<DetLayer const*> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#4  0x00007fffe9dfe78a in
SimpleBarrelNavigableLayer::nextLayers(FreeTrajectoryState const&,
PropagationDirection) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerTkNavigation.so
#5  0x00007fffe76ccf9c in DetLayer::nextLayers(FreeTrajectoryState const&,
PropagationDirection) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libTrackingToolsDetLayers.so
#6  0x00007fffea4d373f in
BaseCkfTrajectoryBuilder::findStateAndLayers(TempTrajectory const&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#7  0x00007fffea4eaab2 in
GroupedCkfTrajectoryBuilder::advanceOneLayer(TempTrajectory&, TrajectoryFilter
const*, Propagator const*, bool, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#8  0x00007fffea4e7f8c in
GroupedCkfTrajectoryBuilder::groupedLimitedCandidates(TempTrajectory&,
TrajectoryFilter const*, Propagator const*, bool, std::vector<TempTrajectory,
std::allocator<TempTrajectory> >&) const ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
#9  0x00007fffea4e90b1 in GroupedCkfTrajectoryBuilder::buildTrajectories ()
   from
/data/CMSSW_4_2_0_pre6/lib/slc5_amd64_gcc451/libRecoTrackerCkfPattern.so
(More stack frames follow...)
(gdb) quit
A debugging session is active.

    Inferior 1 [process 32154] will be killed.

Quit anyway? (y or n) y


(2)

$ /usr/bin/gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) 

$ /lib64/libc.so.6 --version
GNU C Library stable release version 2.12, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.4 20100726 (Red Hat 4.4.4-13).
Compiled on a Linux 2.6.32 system on 2011-04-04.
Available extensions:
    The C stubs add-on version 2.1.2.
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
    RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

(3)

$ /opt/lib/libc.so.6 --version
GNU C Library stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.1 20110408 (prerelease).
Compiled on a Linux 2.6.32 system on 2011-04-13.
Available extensions:
    crypt add-on version 2.1 by Michael Glad and others
    GNU Libidn by Simon Josefsson
    Native POSIX Threads Library by Ulrich Drepper et al
    BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

(4)

0000000000025af0 <__ieee754_lgammaf_r>:
   25af0:       48 89 5c 24 e8          mov    %rbx,-0x18(%rsp)
   25af5:       c5 f8 28 d0             vmovaps %xmm0,%xmm2
   25af9:       48 89 6c 24 f0          mov    %rbp,-0x10(%rsp)
   25afe:       c5 f9 7e c5             vmovd  %xmm0,%ebp
   25b02:       89 eb                   mov    %ebp,%ebx
   25b04:       4c 89 64 24 f8          mov    %r12,-0x8(%rsp)
   25b09:       48 81 ec 88 00 00 00    sub    $0x88,%rsp
   25b10:       81 e3 ff ff ff 7f       and    $0x7fffffff,%ebx

00001ac0 00000024 00001ac4 FDE cie=00000000 pc=00025af0..000263db
  DW_CFA_advance_loc: 20 to 00025b04
  DW_CFA_offset: r6 (rbp) at cfa-24
  DW_CFA_offset: r3 (rbx) at cfa-32
  DW_CFA_advance_loc: 12 to 00025b10
  DW_CFA_def_cfa_offset: 144
  DW_CFA_offset: r12 (r12) at cfa-16
  DW_CFA_advance_loc1: 92 to 00025b6c
  DW_CFA_remember_state
  DW_CFA_def_cfa_offset: 8
  DW_CFA_advance_loc: 4 to 00025b70
  DW_CFA_restore_state
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

(5)

0000000000026e70 <__ieee754_rem_pio2f>:
   26e70:       55                      push   %rbp
   26e71:       48 89 e5                mov    %rsp,%rbp
   26e74:       41 54                   push   %r12
   26e76:       53                      push   %rbx
   26e77:       48 89 fb                mov    %rdi,%rbx
   26e7a:       c4 c1 79 7e c4          vmovd  %xmm0,%r12d
   26e7f:       44 89 e1                mov    %r12d,%ecx
   26e82:       48 83 e4 e0             and    $0xffffffffffffffe0,%rsp
   26e86:       81 e1 ff ff ff 7f       and    $0x7fffffff,%ecx
   26e8c:       48 83 ec 20             sub    $0x20,%rsp

00001b58 0000002c 00001b5c FDE cie=00000000 pc=00026e70..000271ca
  DW_CFA_advance_loc: 1 to 00026e71
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r6 (rbp) at cfa-16
  DW_CFA_advance_loc: 3 to 00026e74
  DW_CFA_def_cfa_register: r6 (rbp)
  DW_CFA_advance_loc: 6 to 00026e7a
  DW_CFA_offset: r3 (rbx) at cfa-32
  DW_CFA_offset: r12 (r12) at cfa-24
  DW_CFA_advance_loc1: 121 to 00026ef3
  DW_CFA_remember_state
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_advance_loc: 5 to 00026ef8
  DW_CFA_restore_state
  DW_CFA_advance_loc1: 197 to 00026fbd
  DW_CFA_remember_state
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_advance_loc: 3 to 00026fc0
  DW_CFA_restore_state
  DW_CFA_nop
  DW_CFA_nop

[Bug c/48597] x86-64 unwind register save location misses half-register write?

[lat at cern dot ch]

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

--- Comment #1 from lat at cern dot ch 2011-04-14 07:53:27 UTC ---
For completeness I didn't look for unwind inaccuracies with half-register
writes other than the exact form "(v)movd %xmmN,%ebp". It's entirely possible
this bug happens only with %xmm -> %ebp writes, but also that it is more
widespread. At any rate, this is the first I've noticed this problem, and the
specific issue I found only exists in four functions - but unfortunately our
code hits those math functions quite hard and inability to unwind through them
is awkward.

[Bug c/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-14 08:22:06 UTC ---
I confirm I can see this problem in RHEL6 libm, on the other side I can't
reproduce with git trunk glibc, even if I compile e_rem_pio2f.c with GCC
4.4-RH, 4.6 or GCC trunk.
.LVL0:
        pushq   %rbp
.LCFI0:
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
.LBB2:
        .loc 1 113 0
#APP
# 113 "../sysdeps/ieee754/flt-32/e_rem_pio2f.c" 1
        movd %xmm0, %ebp
is correct.

[Bug c/48597] x86-64 unwind register save location misses half-register write?

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.04.14 09:22:48
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-14 09:22:48 UTC ---
So - can we have preprocessed source that shows the issue with a GCC FSF
release?

[Bug c/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-14 09:24:22 UTC ---
Working on it.

[Bug c/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-14 12:02:38 UTC ---
extern int bar (float *, float *, int, int, int);
int
foo (float x, float *y)
{
  float z, t[3];
  int e, m, n, i, h;
  int q, r;
  asm ("movd %1, %0" : "=rm" (q) : "x" (x));
  h = q;
  i = h & 0x7fffffff;
  e = (i >> 23) - 134;
  r = i - ((int) (e << 23));
  asm ("movd %1, %0" : "=x" (z) : "rm" (r));
  m = 3;
  n = bar (t, y, e, m, 2);
  if (h < 0)
    {
      y[0] = -y[0];
      y[1] = -y[1];
      return -n;
    }
  return n;
}

at -O2 is a shorter testcase, fails with vanilla 4.4 and 4.5 (and RHEL 6.0
gcc),
works with 4.6/4.7 (and RHEL 6.1 gcc), with
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01557.html
optimization mitigating the bug.  The bug is that dwarf2out_frame_debug isn't
called for inline asm.

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-14 12:35:20 UTC ---
Created attachment 23980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23980
gcc46-pr48597.patch

Untested fix.  Better testcase where the bug isn't mitigated by the CFI
optimization patch mentioned earlier:

void
foo (void)
{
  register long r __asm ("r12");
  register long s __asm ("r13");
  register long t __asm ("r14");
  register long u __asm ("r15");
  asm volatile ("xorq %0, %0" : "=r" (r));
  asm volatile ("xorq %0, %0" : "=r" (s));
  asm volatile ("xorq %0, %0" : "=r" (t));
  asm volatile ("xorq %0, %0" : "=r" (u));
}

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-14 12:38:16 UTC ---
void
foo (void)
{
  register long s __asm ("r13");
  register long t __asm ("r14");
  register long u __asm ("r15");
  asm volatile ("xorq %%r12, %%r12" : : : "r12");
  asm volatile ("xorq %0, %0" : "=r" (s));
  asm volatile ("xorq %0, %0" : "=r" (t));
  asm volatile ("xorq %0, %0" : "=r" (u));
}

Alternative testcase to also test if queued register saves are found in inline
asm clobbers.

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[lat at cern dot ch]

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

--- Comment #8 from Lassi Tuura <lat at cern dot ch> 2011-04-15 05:40:33 UTC ---
I confirm glibc 2.13 built with gcc 4.6.1 20110408 snapshot patched with
gcc46-pr48597.patch results in correct unwind info for __ieee754_lgammaf_r. I
checked all the locations using (v)movd %xmmN,%ebp pattern, and the unwind info
is now correct everywhere. Haven't run any of the newly compiled code yet, will
do that later.

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-28 17:02:01 UTC ---
Author: jakub
Date: Thu Apr 28 17:01:55 2011
New Revision: 173121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173121
Log:
    PR middle-end/48597
    * final.c (final_scan_insn): Call dwarf2out_frame_debug even for
    inline asm.

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/final.c

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-28 17:01:13 UTC ---
Author: jakub
Date: Thu Apr 28 17:01:02 2011
New Revision: 173120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173120
Log:
    PR middle-end/48597
    * final.c (final_scan_insn): Call dwarf2out_frame_debug even for
    inline asm.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/final.c

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-04-28 17:12:25 UTC ---
Fixed for 4.6+.

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-03 16:36:02 UTC ---
Author: jakub
Date: Tue May  3 16:35:56 2011
New Revision: 173327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173327
Log:
    Backport from mainline
    2011-04-28  Jakub Jelinek  <jakub@redhat.com>

    PR middle-end/48597
    * final.c (final_scan_insn): Call dwarf2out_frame_debug even for
    inline asm.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/final.c

[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-04 09:14:07 UTC ---
Author: jakub
Date: Wed May  4 09:14:00 2011
New Revision: 173357

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173357
Log:
    Backport from mainline
    2011-04-28  Jakub Jelinek  <jakub@redhat.com>

    PR middle-end/48597
    * final.c (final_scan_insn): Call dwarf2out_frame_debug even for
    inline asm.

Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/final.c