[Bug middle-end/34725] New: [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[Bug middle-end/34725] New: [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[bero at arklinux dot org]

Any application that uses libgcrypt 1.4.0 (including the parts of "make check"
in libgcrypt) segfaults if libgcrypt was built with gcc 4.3 (svn 131213) and
the CFLAGS setting includes "-O1 [or higher] -mtune=i686 -fomit-frame-pointer"

gdb shows the crash occurs in detect_ia32_gnuc() (defined in src/hwfeatures.c).

Adding a fprintf(stderr, "anything\n"); line anywhere in that function
(regardless where; done as part of locating the issue) makes the segfault go
away.

The segfault also doesn't occur if you just copy the code for
detect_ia32_gnuc() to a separate file and add a main() function calling it.


-- 
           Summary: [4.3 regression] gcc 4.3-rev 131213 miscompiles
                    libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-01-13 15:23 -------
Testcase?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[ismail at pardus dot org dot tr]

------- Comment #2 from ismail at pardus dot org dot tr  2008-01-20 04:57 -------
--disable-padlock fixes the crash so the crashing part is the inline asm that
is under 

#ifdef ENABLE_PADLOCK_SUPPORT .


-- 

ismail at pardus dot org dot tr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ismail at pardus dot org dot
                   |                            |tr


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[bero at arklinux dot org]

------- Comment #3 from bero at arklinux dot org  2008-01-20 11:10 -------
The padlock code itself doesn't crash (if you add anything else near it, the
crash goes away). I suspect something gets messed up in the calling
conventions, and so far haven't been able to reproduce this in a smaller test
case. It's probably a fairly big combination of things that have to come
together to trigger this.


-- 


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

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2008-01-20 19:26 -------
It fails even with gcc 4.1.2 and the same CFLAGS, and the problem is just buggy
inline assembly.
Following patch cures this for me:
--- hwfeatures.c.xx     2007-12-05 12:03:33.000000000 +0100
+++ hwfeatures.c        2008-01-20 19:54:54.000000000 +0100
@@ -79,13 +79,12 @@ detect_ia32_gnuc (void)
     ("pushl %%ebx\n\t"           /* Save GOT register.  */
      "xorl  %%eax, %%eax\n\t"    /* 0 -> EAX.  */
      "cpuid\n\t"                 /* Get vendor ID.  */
-     "leal  %0, %%eax\n\t"       /* EBX,EDX,ECX -> VENDOR_ID.  */
-     "movl  %%ebx, (%%eax)\n\t"
-     "movl  %%edx, 4(%%eax)\n\t"
-     "movl  %%ecx, 8(%%eax)\n\t"
+     "movl  %%ebx, (%1)\n\t"    /* EBX,EDX,ECX -> VENDOR_ID.  */
+     "movl  %%edx, 4(%1)\n\t"
+     "movl  %%ecx, 8(%1)\n\t"
      "popl  %%ebx\n"
      : "=m" (vendor_id)
-     :
+     : "S" (&vendor_id[0])
      : "%eax", "%ecx", "%edx", "cc"
      );
   vendor_id[12] = 0;

The problem is that %0 corresponding to "=m" is expanded when %esp is different
from what it has been originally on inline asm entry (and exit).  Without
-fomit-frame-pointer GCC will usually use (%ebp+N) for %0, but with
-fomit-frame-pointer it uses (%esp+M), but as there is pushl %ebx before this,
it means the inline asm stores to a different location than expected.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


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