[Bug target/53219] New: inline function erroneously clobbers %i0 register on 64 bit sparc comiple of perls regcomp.c

[Bug target/53219] New: inline function erroneously clobbers %i0 register on 64 bit sparc comiple of perls regcomp.c

[martin at netbsd dot org]

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

             Bug #: 53219
           Summary: inline function erroneously clobbers %i0 register on
                    64 bit sparc comiple of perls regcomp.c
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: martin@netbsd.org


gcc 4.5.3 on NetBSD/sparc64 miscompiles perl's regcomp.c file.
Inside the big Perl_re_compile() function with %i0 being "my_perl", the context
for the whole function, it inlines this tiny function:

72      PERL_STATIC_INLINE regex_charset
73      get_regex_charset(const U32 flags)
74      {
75          /* Returns the enum corresponding to the character set in 'flags'
*/
76      
77          return (regex_charset) ((flags & RXf_PMf_CHARSET) >>
_RXf_PMf_CHARSET_SHIFT);
78      }

This is the generated assembler code:

   0x4058f560 <Perl_re_compile+128>:    
    brnz  %g1, 0x4058f570 <Perl_re_compile+144>
   0x4058f564 <Perl_re_compile+132>:    add  %l3, %g1, %l5
   0x4058f568 <Perl_re_compile+136>:    clr  [ %fp + 0x66b ]
   0x4058f56c <Perl_re_compile+140>:    clr  [ %fp + 0x88f ], %i0
   0x4058f574 <Perl_re_compile+148>:    and  %i0, 0xe0, %g1
   0x4058f578 <Perl_re_compile+152>:    srl  %g1, 5, %g1
   0x4058f57c <Perl_re_compile+156>:    cmp  %g1, 1
   0x4058f580 <Perl_re_compile+160>:    
    be,pn   %icc, 0x40590ecc <Perl_re_compile+6636>

Note at the ==> marker, %i0 is reloaded without save before nor any restore
later. This causes a crash shortly later.

Simple test:

   perl -e '/(?{"{"})/'

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #1 from Martin Husemann <martin at netbsd dot org> 2012-05-03 21:34:13 UTC ---
It occured to me that gcc would (rightfully) behave this way, if the (previous)
value in %i0 should be considered dead at this point - which might be the case,
hard to tell due to lots of macro magic [is there some way to easily check
this?].

However, in this function there is a sigsetjmp() call, and in the test case we
return to it. The standard says that non volatile automatic variables which
values changed after the setjmp() call may have the later value on return from
the longjmp - and this probably extrapolates to this type of register usage.
Since %i0 is not callee saved in sparc64, its value is restored on longjmp from
the register window shadow copy on the stack, where it has the later value (0
in the exammple).

So, how could I check this hypothesis?
Is there some attribute magic we could use to hint gcc to keep all values alive
at the setjmp call alive untill the end of the function?

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #2 from Martin Husemann <martin at netbsd dot org> 2012-05-04 07:56:48 UTC ---
I double checked: the sigsetjmp/siglonjmp function prototypes are properly
marked as returns_twice and noreturn, so I claim this to be abug in gcc ;-)

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2012-05-04 08:48:08 UTC ---
Please provide a test case.  See <http://gcc.gnu.org/bugs/#report>.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #4 from Martin Husemann <martin at netbsd dot org> 2012-05-04 13:27:37 UTC ---
Created attachment 27307
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27307
intermediate file when compiling regcomp.c

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #5 from Martin Husemann <martin at netbsd dot org> 2012-05-04 13:29:45 UTC ---
Using built-in specs.
COLLECT_GCC=cc
Target: sparc64--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=sparc64--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb2 20111202' --enable-__cxa_atexit
--with-mpc=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr
--with-mpfr=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr
--with-gmp=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr --enable-tls
--disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0 --host=sparc64--netbsd
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806) 

NetBSD thirdstage.duskware.de 6.99.6 NetBSD 6.99.6 (MODULAR) #37: Thu May  3
10:33:30 CEST 2012 
martin@night-porter.duskware.de:/usr/src/sys/arch/sparc64/compile/MODULAR
sparc64

Command line used:
gcc -DPERL_CORE -c -O2 -pipe -pthread -g -O2 -I/usr/include
-fno-strict-aliasing -fstack-protector -I/usr/pkg/include  -std=c89 -O2 -pipe 
-pthread  -g -O2 -I/usr/include  -Wall -ansi -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings 


I will try to create a smaller test case to reproduce it, but is not easy.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-05-05
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-05-05 19:46:22 UTC ---
> This is the generated assembler code:
> 
>    0x4058f560 <Perl_re_compile+128>:    
>     brnz  %g1, 0x4058f570 <Perl_re_compile+144>
>    0x4058f564 <Perl_re_compile+132>:    add  %l3, %g1, %l5
>    0x4058f568 <Perl_re_compile+136>:    clr  [ %fp + 0x66b ]
>    0x4058f56c <Perl_re_compile+140>:    clr  [ %fp + 0x88f ], %i0
>    0x4058f574 <Perl_re_compile+148>:    and  %i0, 0xe0, %g1
>    0x4058f578 <Perl_re_compile+152>:    srl  %g1, 5, %g1
>    0x4058f57c <Perl_re_compile+156>:    cmp  %g1, 1
>    0x4058f580 <Perl_re_compile+160>:    
>     be,pn   %icc, 0x40590ecc <Perl_re_compile+6636>
> 
> Note at the ==> marker, %i0 is reloaded without save before nor any restore
> later.

The assembly has apparently been mangled, please repost a correct version.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #7 from Martin Husemann <martin at netbsd dot org> 2012-05-06 10:59:19 UTC ---
Created attachment 27324
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27324
gcc -S output for the miscompiled function

The original report showed the disassembler output from gdb; here is the
original compiler output (stripped to the function in question, I can provide
the full output if needed).

The crash happens in the section starting at line 521:

.LLBB1732:
        .loc 1 4563 0
        ldx     [%i0+624], %g1 
        add     %fp, 1695, %o0
        mov     0, %o1
        call    __sigsetjmp14, 0
         stx    %g1, [%fp+1687]
.LLVL2000:
        add     %fp, 1687, %g1
        st      %o0, [%fp+1815]
.LLBE1732:
        .loc 1 4567 0
        andcc   %o0, 0xff, %o1
.LLBB1733:
        .loc 1 4563 0
        stx     %g1, [%i0+624]


on return from the sigsetjmp %i0 is zero and we crash in the last line cited
above.

I think the register %i0 is left as zero after (post first call to sigsetjmp)
when going throught he code starting at line 77:

.LLVL1968:
.LL2453:
.LLBB1694:
.LLBB1695:
        .loc 3 77 0  
        ldx     [%fp+2191], %i0
.LLVL1969: 
.LL2734:  
        and     %i0, 224, %g1
        srl     %g1, 5, %g1
.LLVL1970:  
.LLBE1695:
.LLBE1694:
        .loc 1 4617 0 
        cmp     %g1, 1

This register value later gets saved to the on-stack copy of the register
window, from where it is restored on siglongjmp.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
         AssignedTo|unassigned at gcc dot       |ebotcazou at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-05-07 13:38:15 UTC ---
Investigating.

[Bug target/53219] inlined function erroneously clobbers %i0 register

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-06-17 09:18:29 UTC ---
First anniversary today. :-)  Upgrade your compiler or backport the fix.

*** This bug has been marked as a duplicate of bug 48542 ***