[Bug c/58066] New: GCC mis-compiles access to TLS variable with -fPIC on x86_64

[Bug c/58066] New: GCC mis-compiles access to TLS variable with -fPIC on x86_64

[ppluzhnikov at google dot com]

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

            Bug ID: 58066
           Summary: GCC mis-compiles access to TLS variable with -fPIC on
                    x86_64
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppluzhnikov at google dot com

Google ref: b/10151411

Reproduced with current trunk, but is broken since at least gcc-4.3.1.

On Linux/x86_64, libstdc++.so.6 __cxa_get_globals looks like so:

Dump of assembler code for function __cxa_get_globals:
   0x00000000000cb430 <+0>:     lea    0x233131(%rip),%rdi
   0x00000000000cb437 <+7>:     callq  0x4f570 <__tls_get_addr@plt>
   0x00000000000cb43c <+12>:    add    $0x0,%rax
   0x00000000000cb442 <+18>:    retq   

This calls external function __tls_get_addr with mis-aligned stack.
__tls_get_addr may itself call malloc, and malloc is user-replaceable,
and may assume that stack is properly aligned (and crash when it isn't).

Trivial test case:


static __thread char ccc;
extern "C" void* __cxa_get_globals() throw()
{
 return &ccc;
}

  g++ -fPIC -S -O2 t.cc

results in:

__cxa_get_globals:
       leaq    _ZL3ccc@tlsld(%rip), %rdi
       call    __tls_get_addr@PLT
       addq    $_ZL3ccc@dtpoff, %rax
       ret



Ian Lance Taylor says:

  There is code in the i386 backend that is designed to avoid this.
  However, it appears to have only been fully implemented for the GNU2 TLS
  descriptor style ...

  I suspect that the right fix is to add the line

     ix86_tls_descriptor_calls_expanded_in_cfun = true;

  to tls_global_dynamic_64_<mode> and tls_local_dynamic_base_64_<mode>
  in gcc/config/i386/i386.md.

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> However, it appears to have only been fully implemented for the GNU2 TLS
>  descriptor style ...

Which most Linux distro default to anyways ...

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[ppluzhnikov at google dot com]

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

--- Comment #3 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to Paul Pluzhnikov from comment #2)

> What is the way to turn it on?

Compiling test case with -mtls-dialect=gnu2 does appear to improve the picture:

g++ -fPIC -O2 -S t.cc -mtls-dialect=gnu2

__cxa_get_globals:
        leaq    _ZL3ccc@TLSDESC(%rip), %rax
        call    *_ZL3ccc@TLSCALL(%rax)
        addq    %fs:0, %rax
        ret

The indirect call goes to _dl_tlsdesc_dynamic in ld-linux-x86-64.so.2 with
misaligned stack, and the latter re-aligns it.

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 32341
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32341&action=edit
A patch

This patch sets ix86_tls_descriptor_calls_expanded_in_cfun after
reload is complete and checks it for stack boundary in
ix86_frame_pointer_required.

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Another problem:

[hjl@gnu-6 gcc]$ cat /tmp/c.i 
static __thread char ccc;

void* __cxa_get_globals()
{
 return &ccc;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i 
[hjl@gnu-6 gcc]$ cat /tmp/c.i 
static __thread char ccc;

void* __cxa_get_globals()
{
 return &ccc;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i  -m32
[hjl@gnu-6 gcc]$ cat c.s
    .file    "c.i"
    .section    .text.unlikely,"ax",@progbits
.LCOLDB0:
    .text
.LHOTB0:
    .p2align 4,,15
    .globl    __cxa_get_globals
    .type    __cxa_get_globals, @function
__cxa_get_globals:
.LFB0:
    .cfi_startproc
    pushl    %ebx
    .cfi_def_cfa_offset 8
    .cfi_offset 3, -8
    call    __x86.get_pc_thunk.bx
    addl    $_GLOBAL_OFFSET_TABLE_, %ebx
    subl    $8, %esp
    .cfi_def_cfa_offset 16
    addl    $8, %esp
    .cfi_def_cfa_offset 8
    leal    ccc@tlsgd(,%ebx,1), %eax
    call    ___tls_get_addr@PLT
    popl    %ebx
    .cfi_restore 3
    .cfi_def_cfa_offset 4
    ret
    .cfi_endproc
.LFE0:
    .size    __cxa_get_globals, .-__cxa_get_globals

sched2 doesn't know

(insn:TI 15 25 13 2 (parallel [
            (set (reg:SI 0 ax [86])
                (unspec:SI [
                        (reg:SI 3 bx)
                        (symbol_ref:SI ("ccc") [flags 0x1a]  <var_decl
0x7f2b2be
5e980 ccc>)
                        (symbol_ref:SI ("___tls_get_addr"))
                    ] UNSPEC_TLS_GD))
            (clobber (reg:SI 1 dx [88]))
            (clobber (reg:SI 2 cx [89]))
            (clobber (reg:CC 17 flags))
        ]) /tmp/c.i:5 772 {*tls_global_dynamic_32_gnu}
     (expr_list:REG_DEAD (reg:SI 3 bx)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (expr_list:REG_UNUSED (reg:SI 2 cx [89])
                (expr_list:REG_UNUSED (reg:SI 1 dx [88])
                    (expr_list:REG_EQUIV (unspec:SI [
                                (reg:SI 3 bx)
                                (symbol_ref:SI ("ccc") [flags 0x1a]  <var_decl
0
x7f2b2be5e980 ccc>)
                                (symbol_ref:SI ("___tls_get_addr"))
                            ] UNSPEC_TLS_GD)
                        (nil)))))))

is a function call and move stack adjustment cross it.

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[wmi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #7 from wmi at gcc dot gnu.org ---
Author: wmi
Date: Mon May 19 05:25:45 2014
New Revision: 210601

URL: http://gcc.gnu.org/viewcvs?rev=210601&root=gcc&view=rev
Log:
2014-05-18  Wei Mi  <wmi@google.com>

        PR target/58066
        * gcc.target/i386/pr58066.c: Replace pattern matching of .cfi
        directive with rtl insns. Add effective-target of fpic and
        tls_native.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/i386/pr58066.c

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #8 from Dmitry Vyukov <dvyukov at google dot com> ---
Is there any progress on this? Is it fixed?

I've hit this issue in ThreadSanitizer. It intercepts __tls_get_addr and then
code that uses MOVDQA [rbp] crashes. I remember that I hit it previously in
some other context as well.

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-11
                 CC|                            |ubizjak at gmail dot com
            Version|unknown                     |6.0
   Target Milestone|---                         |6.0
            Summary|GCC mis-compiles access to  |__tls_get_addr is called
                   |TLS variable with -fPIC on  |with misaligned stack on
                   |x86_64                      |x86-64
     Ever confirmed|0                           |1

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
__tls_get_addr is called with misaligned stack on x86-64. It
crashes ld.so when it tries to save and restore XMM registers
with aligned load/store:

https://sourceware.org/ml/libc-alpha/2015-07/msg00365.html

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
Another testcase:

[hjl@gnu-tools-1 pr58066]$ cat x.i
struct in_addr
  {
    int s_addr;
  };

typedef long unsigned int size_t;
extern void __snprintf (char *__restrict __s, size_t __maxlen,
         const char *__restrict __format, ...)
     __attribute__ ((__format__ (__printf__, 3, 4)));

static __thread char buffer[18];

char *
inet_ntoa (struct in_addr in)
{
  unsigned char *bytes = (unsigned char *) &in;
  __snprintf (buffer, sizeof (buffer), "%d.%d.%d.%d",
       bytes[0], bytes[1], bytes[2], bytes[3]);

  return buffer;
}
[hjl@gnu-tools-1 pr58066]$ gcc -S -fPIC -O2 x.i
[hjl@gnu-tools-1 pr58066]$ cat x.s
        .file   "x.i"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC0:
        .string "%d.%d.%d.%d"
        .section        .text.unlikely,"ax",@progbits
.LCOLDB1:
        .text
.LHOTB1:
        .p2align 4,,15
        .globl  inet_ntoa
        .type   inet_ntoa, @function
inet_ntoa:
.LFB0:
        .cfi_startproc
        pushq   %r14
        .cfi_def_cfa_offset 16
        .cfi_offset 14, -16
        pushq   %r13
        .cfi_def_cfa_offset 24
        .cfi_offset 13, -24
        movzbl  %dil, %r13d
        pushq   %r12
        .cfi_def_cfa_offset 32
        .cfi_offset 12, -32
        pushq   %rbp
        .cfi_def_cfa_offset 40
        .cfi_offset 6, -40
        movl    %edi, %r12d
        pushq   %rbx
        .cfi_def_cfa_offset 48
        .cfi_offset 3, -48
        movl    %edi, %ebx
        shrl    $16, %r12d
        movzbl  %bh, %eax
        shrl    $24, %ebx
        movzbl  %r12b, %r12d
        subq    $8, %rsp
        .cfi_def_cfa_offset 56
        movl    %eax, %r14d
        leaq    buffer@tlsld(%rip), %rdi
        call    __tls_get_addr@PLT
        pushq   %rbx
        .cfi_def_cfa_offset 64
        leaq    .LC0(%rip), %rdx
        movl    %r12d, %r9d
        leaq    buffer@dtpoff(%rax), %rbp
        movl    %r14d, %r8d
        movl    %r13d, %ecx
        xorl    %eax, %eax
        movl    $18, %esi
        movq    %rbp, %rdi
        call    __snprintf@PLT
        popq    %rax
        .cfi_def_cfa_offset 56
        movq    %rbp, %rax
        popq    %rdx
        .cfi_def_cfa_offset 48
        popq    %rbx
        .cfi_def_cfa_offset 40
        popq    %rbp
        .cfi_def_cfa_offset 32
        popq    %r12
        .cfi_def_cfa_offset 24
        popq    %r13
        .cfi_def_cfa_offset 16
        popq    %r14
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE0:
        .size   inet_ntoa, .-inet_ntoa
        .section        .text.unlikely
.LCOLDE1:
        .text
.LHOTE1:
        .section        .tbss,"awT",@nobits
        .type   buffer, @object
        .size   buffer, 18
buffer:
        .zero   18
        .ident  "GCC: (GNU) 5.1.1 20150707 (Red Hat 5.1.1-5)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 pr58066]$ 

__tls_get_addr is called with misaligned stack.

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
Please make 64bit TLS patterns dependant on SP_REG, in the same way as 32bit
are.
>From gcc-bugs-return-492113-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 13 07:44:42 2015
Return-Path: <gcc-bugs-return-492113-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62918 invoked by alias); 13 Jul 2015 07:44:41 -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 62854 invoked by uid 48); 13 Jul 2015 07:44:38 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/66752] spec2000 255.vortex performance compiled with GCC is ~20% lower than with CLANG
Date: Mon, 13 Jul 2015 07:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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: keywords bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-66752-4-FFadnjsY9p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66752-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66752-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: 2015-07/txt/msg01003.txt.bz2
Content-length: 813

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf752

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-13
                 CC|                            |law at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is simply a jump-threading opportunity that is not taken (with the
complication that this threads through the loop header).  I wonder
whether the FSM thereading machiner could catch this though.

[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #11)
> Please make 64bit TLS patterns dependant on SP_REG, in the same way as 32bit
> are.

This wont't fix this particular case, but this dependency would be nice to
have.

The problem with the testcase from Comment #10 is caused by stack
anti-adjustment, emitted from calls.c:

    1: NOTE_INSN_DELETED
    4: NOTE_INSN_BASIC_BLOCK 2
    2: r96:SI=di:SI
    3: NOTE_INSN_FUNCTION_BEG
    6: {sp:DI=sp:DI-0x8;clobber flags:CC;}               <<--- *** here ***
      REG_ARGS_SIZE 0x8
    7: {r98:SI=r96:SI 0>>0x10;clobber flags:CC;}
    8: {r99:QI=r98:SI#0&0xffffffffffffffff;clobber flags:CC;}
    9: r100:SI=zero_extend(r99:QI)
   10: r101:QI#0=zero_extract(r96:SI,0x8,0x8)
   11: r102:SI=zero_extend(r101:QI)
   12: r103:SI=zero_extend(r96:SI#0)
   13: ax:DI=call [`__tls_get_addr'] argc:0
      REG_EH_REGION 0xffffffff80000000
   14: r105:DI=ax:DI
      REG_EQUAL unspec[0] 21
   15: {r106:DI=r105:DI+const(unspec[`buffer'] 6);clobber flags:CC;}
   16: r104:DI=r106:DI
      REG_EQUAL `buffer'
   17: {r108:SI=r96:SI 0>>0x18;clobber flags:CC;}
   18: r109:SI=zero_extend(r108:SI#0)
   19: [pre sp:DI+=0xfffffffffffffff8]=r109:SI
      REG_ARGS_SIZE 0x10
   20: r9:SI=r100:SI
   21: r8:SI=r102:SI
   22: cx:SI=r103:SI
   23: dx:DI=`*.LC0'
   24: si:DI=0x12
   25: di:DI=r104:DI
   26: ax:QI=0
   27: call [`__snprintf'] argc:0x10
      REG_CALL_DECL `__snprintf'
   28: ax:DI=call [`__tls_get_addr'] argc:0
      REG_EH_REGION 0xffffffff80000000
   29: r111:DI=ax:DI
      REG_EQUAL unspec[0] 21
   30: {r112:DI=r111:DI+const(unspec[`buffer'] 6);clobber flags:CC;}
   31: r95:DI=r112:DI
      REG_EQUAL `buffer'
   32: {sp:DI=sp:DI+0x10;clobber flags:CC;}
      REG_ARGS_SIZE 0
   36: ax:DI=r95:DI
   37: use ax:DI

Putting a breakpoint on anti_adjust_stack will show where it happens:

Breakpoint 1, anti_adjust_stack (adjust=0x2aaaae7b0500) at
/home/uros/gcc-svn/trunk/gcc/explow.c:902
902       if (adjust == const0_rtx)
(gdb) bt
#0  anti_adjust_stack (adjust=0x2aaaae7b0500) at
/home/uros/gcc-svn/trunk/gcc/explow.c:902
#1  0x000000000080f24c in expand_call (exp=0x2aaaae7b3680, target=0x0,
ignore=1) at /home/uros/gcc-svn/trunk/gcc/calls.c:3165
#2  0x0000000000966084 in expand_expr_real_1 (exp=0x2aaaae7b3680, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=false)
    at /home/uros/gcc-svn/trunk/gcc/expr.c:10362

There is already precompute_register_parameters function where:

        /* If the value is a non-legitimate constant, force it into a
           pseudo now.  TLS symbols sometimes need a call to resolve.  */
        if (CONSTANT_P (args[i].value)
            && !targetm.legitimate_constant_p (args[i].mode, args[i].value))
          args[i].value = force_reg (args[i].mode, args[i].value);

So, the core of the problem is in the call infrastructure that should emit
precomputed register parameters before anti_adjust_stack is emitted

After this infrastructure problem is fixed, proposed SP_REG dependency will
prevent stack adjustment to be scheduled above TLS patterns.

Re-confirmed as RTL-optimization problem.
>From gcc-bugs-return-492122-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 13 09:20:40 2015
Return-Path: <gcc-bugs-return-492122-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 63063 invoked by alias); 13 Jul 2015 09:20:40 -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 63026 invoked by uid 48); 13 Jul 2015 09:20:36 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
Date: Mon, 13 Jul 2015 09:20: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.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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 cc resolution
Message-ID: <bug-66852-4-9VNBsu7hKp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66852-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66852-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: 2015-07/txt/msg01012.txt.bz2
Content-length: 3903

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf852

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |trippels at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
If you build with -fsanitize=undefined you'll see:

algparam.h:204:87: runtime error: reference binding to null pointer of type
'const struct Integer'
algparam.h:217:88: runtime error: reference binding to null pointer of type
'const struct Integer'
algparam.h:220:88: runtime error: reference binding to null pointer of type
'const struct Integer'
crc.cpp:134:28: runtime error: load of misaligned address 0x00000127df9f for
type 'const word32', which requires 4 byte alignment
filters.cpp:280:39: runtime error: null pointer passed as argument 1, which is
declared to never be null
filters.cpp:280:39: runtime error: null pointer passed as argument 2, which is
declared to never be null
filters.cpp:281:50: runtime error: null pointer passed as argument 1, which is
declared to never be null
filters.cpp:281:50: runtime error: null pointer passed as argument 2, which is
declared to never be null
filters.cpp:291:28: runtime error: null pointer passed as argument 1, which is
declared to never be null
filters.cpp:518:84: runtime error: null pointer passed as argument 1, which is
declared to never be null
filters.cpp:518:84: runtime error: null pointer passed as argument 2, which is
declared to never be null
filters.cpp:676:35: runtime error: null pointer passed as argument 2, which is
declared to never be null
misc.cpp:101:29: runtime error: load of misaligned address 0x7ffdab82d529 for
type 'word32', which requires 4 byte alignment
misc.cpp:101:50: runtime error: load of misaligned address 0x00000127df95 for
type 'word32', which requires 4 byte alignment
misc.cpp:26:43: runtime error: load of misaligned address 0x7ffdab82c713 for
type 'word64', which requires 8 byte alignment
misc.cpp:35:43: runtime error: load of misaligned address 0x000003c65c4a for
type 'word32', which requires 4 byte alignment
misc.cpp:56:68: runtime error: store to misaligned address 0x000003c67653 for
type 'word64', which requires 8 byte alignment
misc.cpp:66:67: runtime error: store to misaligned address 0x000003c67651 for
type 'word32', which requires 4 byte alignment
misc.cpp:91:30: runtime error: load of misaligned address 0x7ffdab82d511 for
type 'word64', which requires 8 byte alignment
misc.h:1163:31: runtime error: load of misaligned address 0x00000127d8aa for
type 'const unsigned int', which requires 4 byte alignment
misc.h:1181:2: runtime error: load of misaligned address 0x000003c67669 for
type 'const unsigned int', which requires 4 byte alignment
misc.h:177:26: runtime error: null pointer passed as argument 2, which is
declared to never be null
misc.h:623:22: runtime error: shift exponent 32 is too large for 32-bit type
'unsigned int'
misc.h:635:22: runtime error: shift exponent 32 is too large for 32-bit type
'unsigned int'
misc.h:641:22: runtime error: shift exponent 32 is too large for 32-bit type
'unsigned int'
misc.h:962:23: runtime error: load of misaligned address 0x7ffdab82c702 for
type 'const long long unsigned int', which requires 8 byte alignment
panama.cpp:371:11: runtime error: load of misaligned address 0x7ffdab82c716 for
type 'const word32', which requires 4 byte alignment
panama.cpp:371:18: runtime error: load of misaligned address 0x7ffdab82c71a for
type 'const word32', which requires 4 byte alignment
panama.cpp:371:25: runtime error: load of misaligned address 0x7ffdab82c71e for
type 'const word32', which requires 4 byte alignment
... etc.

[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 35964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35964&action=edit
Combined middle/end/target patch

Patch in testing.
>From gcc-bugs-return-492139-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 13 11:11:00 2015
Return-Path: <gcc-bugs-return-492139-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8809 invoked by alias); 13 Jul 2015 11:10:59 -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 8532 invoked by uid 48); 13 Jul 2015 11:10:56 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
Date: Mon, 13 Jul 2015 11:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58066-4-Lx62pn0Z7E@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58066-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58066-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01029.txt.bz2
Content-length: 3139

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #13)

> Patch in testing.

This patch fixes the testcase, now we get:

0000000000000000 <inet_ntoa>:
   0:   41 56                   push   %r14
   2:   41 55                   push   %r13
   4:   44 0f b6 ef             movzbl %dil,%r13d
   8:   41 54                   push   %r12
   a:   55                      push   %rbp
   b:   41 89 fc                mov    %edi,%r12d
   e:   53                      push   %rbx
   f:   89 fb                   mov    %edi,%ebx
  11:   41 c1 ec 10             shr    $0x10,%r12d
  15:   0f b6 c7                movzbl %bh,%eax
  18:   c1 eb 18                shr    $0x18,%ebx
  1b:   45 0f b6 e4             movzbl %r12b,%r12d
  1f:   41 89 c6                mov    %eax,%r14d
  22:   48 8d 3d 00 00 00 00    lea    0(%rip),%rdi        # 29
<inet_ntoa+0x29>
                        25: R_X86_64_TLSLD      buffer+0xfffffffffffffffc
  29:   e8 00 00 00 00          callq  2e <inet_ntoa+0x2e>
                        2a: R_X86_64_PLT32     
__tls_get_addr+0xfffffffffffffffc
  2e:   48 83 ec 08             sub    $0x8,%rsp
  32:   48 8d 15 00 00 00 00    lea    0(%rip),%rdx        # 39
<inet_ntoa+0x39>
                        35: R_X86_64_PC32       .LC0+0xfffffffffffffffc
  39:   45 89 e1                mov    %r12d,%r9d
  3c:   48 8d a8 00 00 00 00    lea    0x0(%rax),%rbp
                        3f: R_X86_64_DTPOFF32   buffer
  43:   53                      push   %rbx
  44:   45 89 f0                mov    %r14d,%r8d
  47:   44 89 e9                mov    %r13d,%ecx
  4a:   31 c0                   xor    %eax,%eax
  4c:   be 12 00 00 00          mov    $0x12,%esi
  51:   48 89 ef                mov    %rbp,%rdi
  54:   e8 00 00 00 00          callq  59 <inet_ntoa+0x59>
                        55: R_X86_64_PLT32      __snprintf+0xfffffffffffffffc
  59:   58                      pop    %rax
  5a:   48 89 e8                mov    %rbp,%rax
  5d:   5a                      pop    %rdx
  5e:   5b                      pop    %rbx
  5f:   5d                      pop    %rbp
  60:   41 5c                   pop    %r12
  62:   41 5d                   pop    %r13
  64:   41 5e                   pop    %r14
  66:   c3                      retq   

The difference between patched (+++) and unpatched (---) code is:

--- pr58066_.s  2015-07-13 11:58:23.000000000 +0200
+++ pr58066.s   2015-07-13 11:58:26.000000000 +0200
@@ -28,16 +28,16 @@
        movzbl  %bh, %eax
        shrl    $24, %ebx
        movzbl  %r12b, %r12d
-       subq    $8, %rsp
-.LCFI5:
        movl    %eax, %r14d
        leaq    buffer@tlsld(%rip), %rdi
        call    __tls_get_addr@PLT
-       pushq   %rbx
-.LCFI6:
+       subq    $8, %rsp
+.LCFI5:
        leaq    .LC0(%rip), %rdx
        movl    %r12d, %r9d
        leaq    buffer@dtpoff(%rax), %rbp
+       pushq   %rbx
+.LCFI6:
        movl    %r14d, %r8d
        movl    %r13d, %ecx
        xorl    %eax, %eax

HJ, can you please test the patch if it fixes your problem?
>From gcc-bugs-return-492140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 13 11:14:11 2015
Return-Path: <gcc-bugs-return-492140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 35926 invoked by alias); 13 Jul 2015 11:14:11 -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 35882 invoked by uid 48); 13 Jul 2015 11:14:07 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
Date: Mon, 13 Jul 2015 11:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65709-4-FljcucJhMR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65709-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65709-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: 2015-07/txt/msg01030.txt.bz2
Content-length: 795

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide709

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm saying that if the program does not trigger undefined behavior (e.g. by
accessing misaligned integers without telling the compiler about it (by using
memcpy, or packed attribute or pragma), then it would be a compiler bug to use
an instruction requiring higher alignment than guaranteed in the source,
without ensuring such alignment (through realigning arrays, introducing a loop
for aligning pointers before the vectorized loop, peeling a few iterations
needed to align the pointer(s), or using instructions that don't require such
high alignment).
No testcase has been provided here without having undefined behavior in them
that would show a bug on the compiler side.

[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #13)
> Created attachment 35964 [details]
> Combined middle/end/target patch
> 
> Patch in testing.

I tried it on GCC 5 and it works on glibc.  Thanks.
>From gcc-bugs-return-492148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 13 12:20:09 2015
Return-Path: <gcc-bugs-return-492148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 130356 invoked by alias); 13 Jul 2015 12:20:09 -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 130337 invoked by uid 48); 13 Jul 2015 12:20:05 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions
Date: Mon, 13 Jul 2015 12:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-66855-4-JqPfLINkSY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66855-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66855-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: 2015-07/txt/msg01038.txt.bz2
Content-length: 558

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf855

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-07-13
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
mine

[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jul 15 07:39:30 2015
New Revision: 225807

URL: https://gcc.gnu.org/viewcvs?rev=225807&root=gcc&view=rev
Log:
        PR rtl-optimization/58066
        * calls.c (expand_call): Precompute register parameters before stack
        alignment is performed.


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

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64
          Component|rtl-optimization            |target

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
Back to target component.
>From gcc-bugs-return-492304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 15 08:01:26 2015
Return-Path: <gcc-bugs-return-492304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 96313 invoked by alias); 15 Jul 2015 08:01:26 -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 95955 invoked by uid 48); 15 Jul 2015 08:01:22 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65956] [5/6 Regression] Another ARM overaligned arg passing issue
Date: Wed, 15 Jul 2015 08:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-65956-4-eZHhU1NOwD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65956-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65956-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: 2015-07/txt/msg01194.txt.bz2
Content-length: 522

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide956

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ramana at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #7 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Fixed for 5.2 ?

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #18 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jul 15 13:42:07 2015
New Revision: 225829

URL: https://gcc.gnu.org/viewcvs?rev=225829&root=gcc&view=rev
Log:
        PR target/58066
        * config/i386/i386.md (*tls_global_dynamic_64_<mode>): Depend on
SP_REG.
        (*tls_local_dynamic_base_64_<mode>): Ditto.
        (*tls_local_dynamic_base_64_largepic): Ditto.
        (tls_global_dynamic_64_<mode>): Update expander pattern.
        (tls_local_dynamic_base_64_<mode>): Ditto.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #19 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul 23 18:51:56 2015
New Revision: 226119

URL: https://gcc.gnu.org/viewcvs?rev=226119&root=gcc&view=rev
Log:
        Backport from mainline:
        2015-07-17  Uros Bizjak  <ubizjak@gmail.com>

        PR rtl-optimization/66891
        * calls.c (expand_call): Wrap precompute_register_parameters with
        NO_DEFER_POP/OK_DEFER_POP to prevent deferred pops.

        2015-07-15  Uros Bizjak  <ubizjak@gmail.com>

        PR target/58066
        * config/i386/i386.md (*tls_global_dynamic_64_<mode>): Depend on
SP_REG.
        (*tls_local_dynamic_base_64_<mode>): Ditto.
        (*tls_local_dynamic_base_64_largepic): Ditto.
        (tls_global_dynamic_64_<mode>): Update expander pattern.
        (tls_local_dynamic_base_64_<mode>): Ditto.

        2015-07-15  Uros Bizjak  <ubizjak@gmail.com>

        PR rtl-optimization/58066
        * calls.c (expand_call): Precompute register parameters before stack

testsuite/ChangeLog:

        Backport from mainline:
        2015-07-17  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66891
        * gcc.target/i386/pr66891.c: New test.


Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66891.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/calls.c
    branches/gcc-5-branch/gcc/config/i386/i386.md
    branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul 30 08:53:48 2015
New Revision: 226389

URL: https://gcc.gnu.org/viewcvs?rev=226389&root=gcc&view=rev
Log:
        Backport from mainline:
        2015-07-17  Uros Bizjak  <ubizjak@gmail.com>

        PR rtl-optimization/66891
        * calls.c (expand_call): Wrap precompute_register_parameters with
        NO_DEFER_POP/OK_DEFER_POP to prevent deferred pops.

        2015-07-15  Uros Bizjak  <ubizjak@gmail.com>

        PR target/58066
        * config/i386/i386.md (*tls_global_dynamic_64_<mode>): Depend on
SP_REG.
        (*tls_local_dynamic_base_64_<mode>): Ditto.
        (*tls_local_dynamic_base_64_largepic): Ditto.
        (tls_global_dynamic_64_<mode>): Update expander pattern.
        (tls_local_dynamic_base_64_<mode>): Ditto.

        2015-07-15  Uros Bizjak  <ubizjak@gmail.com>

        PR rtl-optimization/58066
        * calls.c (expand_call): Precompute register parameters before stack
        alignment is performed.

        2014-05-08  Wei Mi  <wmi@google.com>

        PR target/58066
        * config/i386/i386.c (ix86_compute_frame_layout): Update
        preferred_stack_boundary for call, expanded from tls descriptor.
        * config/i386/i386.md (*tls_global_dynamic_32_gnu): Update RTX
        to depend on SP register.
        (*tls_local_dynamic_base_32_gnu): Ditto.
        (*tls_local_dynamic_32_once): Ditto.
        (tls_global_dynamic_64_<mode>): Set
        ix86_tls_descriptor_calls_expanded_in_cfun.
        (tls_local_dynamic_base_64_<mode>): Ditto.
        (tls_global_dynamic_32): Set
        ix86_tls_descriptor_calls_expanded_in_cfun. Update RTX
        to depend on SP register.
        (tls_local_dynamic_base_32): Ditto.

testsuite/ChangeLog:

        Backport from mainline:
        2015-07-17  Uros Bizjak  <ubizjak@gmail.com>

        PR target/66891
        * gcc.target/i386/pr66891.c: New test.

        2014-05-18  Wei Mi  <wmi@google.com>

        PR target/58066
        * gcc.target/i386/pr58066.c: Replace pattern matching of .cfi
        directive with rtl insns. Add effective-target fpic and
        tls_native.

        2014-05-08  Wei Mi  <wmi@google.com>

        PR target/58066
        * gcc.target/i386/pr58066.c: New test.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr58066.c
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66891.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.c
    branches/gcc-4_9-branch/gcc/config/i386/i386.md
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|6.0                         |4.9.4

--- Comment #21 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed everywhere.
>From gcc-bugs-return-493737-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 30 09:01:46 2015
Return-Path: <gcc-bugs-return-493737-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51957 invoked by alias); 30 Jul 2015 09:01:46 -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 51907 invoked by uid 48); 30 Jul 2015 09:01:42 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
Date: Thu, 30 Jul 2015 09:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-67002-4-jXZFaeRVQY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67002-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67002-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: 2015-07/txt/msg02627.txt.bz2
Content-length: 1104

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg002

--- Comment #10 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Oleg Endo from comment #9)
> Not sure if this is a good idea.

I actually think it is the best option as chances are dim otherwise that we
find what's actually causing this register indeterminacy.

Looking at the build log, it's only gcc/real.o where the comparison fails, all
the others (except for the checksum files) are find. I think chances are that,
if this is actually a real bug, it might show itself more pronounced when we
use gcc-5 to build other packages.

Just look at how many bugs we were able to find in gcc-4.9 while using it as
the standard host compiler on Debian sh4.

You are right that ignoring this failure is most certainly not the best on a
release architecture that people rely on. But currently, Debian on sh4 is
merely just a port and things are expected to break from time to time.

I am currently building now a patched gcc-5_5.2.1-12 which has gcc/real.o added
to compare_exclusions, let's see how far we get.

Adrian