[Bug sanitizer/60038] New: AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[Bug sanitizer/60038] New: AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

            Bug ID: 60038
           Summary: AddressSanitizer CHECK failed ... "((*tls_addr +
                    *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS
                    5.10
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
            Target: x86_64-linux-gnu

Many tests in address sanitizer testsuite fail on CentOS 5.10, on x86_64 64bit
target:

FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_PthreadExitTest execution
test
FAIL: g++.dg/asan/asan_test.C  -O2 
AddressSanitizer_ThreadedStressStackReuseTest execution test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_ThreadNamesTest execution
test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_ThreadedTest
ThreadedTestSpawn() output pattern test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_ThreadStackReuseTest
execution test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_ManyThreadsTest execution
test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_ThreadedMallocStressTest
execution test
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O0  output pattern test, is
==28946==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti
zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size))
<= ((*stk_addr + *stk_size))" (0x2ba95e3ff240, 0x2ba95e3ff000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O1  output pattern test, is
==28972==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti
zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size))
<= ((*stk_addr + *stk_size))" (0x2b904ae5e240, 0x2b904ae5e000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O2  output pattern test, is
==28990==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti
zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size))
<= ((*stk_addr + *stk_size))" (0x2b7261726240, 0x2b7261726000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O3 -fomit-frame-pointer  output
pattern test, is ==29015==AddressSanitizer CHECK failed: ../../../../gc
c-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260
"((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b7f30b2f240
, 0x2b7f30b2f000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O3 -g  output pattern test, is
==29038==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsan
itizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr +
*tls_size)) <= ((*stk_addr + *stk_size))" (0x2ae7a3e97240, 0x2ae7a3e97000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -Os  output pattern test, is
==29078==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/libsaniti
zer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr + *tls_size))
<= ((*stk_addr + *stk_size))" (0x2b8e40e38240, 0x2b8e40e38000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O2 -flto -flto-partition=none  output
pattern test, is ==29134==AddressSanitizer CHECK failed: ../../..
/../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260
"((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" (0x2b1d04
5f7240, 0x2b1d045f7000)
FAIL: g++.dg/asan/deep-thread-stack-1.C  -O2 -flto  output pattern test, is
==29196==AddressSanitizer CHECK failed: ../../../../gcc-svn/trunk/lib
sanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr +
*tls_size)) <= ((*stk_addr + *stk_size))" (0x2b99bff03240, 0x2b99bff0300
0)

All these fail on the same check, in the same way. The same tests also fail on
i686 32bit targets, with different addresses, e.g.:

FAIL: g++.dg/asan/deep-thread-stack-1.C  -O0  output pattern test, is
==2673==AddressSanitizer CHECK failed: ../../../../../gcc-svn/trunk/libsani
tizer/sanitizer_common/sanitizer_linux_libcdep.cc:260 "((*tls_addr +
*tls_size)) <= ((*stk_addr + *stk_size))" (0xf6592020, 0xf6592000)

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
I expect this also happens with the clang version of ASAN, please confirm.

This is related to the hackish way we extract stack and tls bounds,
and CentOS 5.10 may have different version of glibc or some other difference.
What is the version of glibc on your OS?

We are trying to solve it in a general way in glibc
(https://sourceware.org/bugzilla/show_bug.cgi?id=16291),
but that will not happen for the existing distros.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Kostya Serebryany from comment #1)
> I expect this also happens with the clang version of ASAN, please confirm.

Unfortunately, I don't have clang installed on this (fairly old) machine, so
I'm not able to confirm this issue.

> This is related to the hackish way we extract stack and tls bounds,
> and CentOS 5.10 may have different version of glibc or some other difference.
> What is the version of glibc on your OS?

$ /lib/libc.so.6 
GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 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.1.2 20080704 (Red Hat 4.1.2-54).
Compiled on a Linux 2.6.9 system on 2013-10-08.
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
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
>From gcc-bugs-return-442351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 08:30:27 2014
Return-Path: <gcc-bugs-return-442351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6319 invoked by alias); 3 Feb 2014 08:30:27 -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 6245 invoked by uid 48); 3 Feb 2014 08:30:24 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
Date: Mon, 03 Feb 2014 08:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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-60038-4-2wpwEMzJem@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60038-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60038-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: 2014-02/txt/msg00108.txt.bz2
Content-length: 866

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
> This is related to the hackish way we extract stack and tls bounds,
> and CentOS 5.10 may have different version of glibc or some other difference.
> What is the version of glibc on your OS?

Looking at libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

#if defined(__x86_64__) || defined(__i386__)
// sizeof(struct thread) from glibc.
// There has been a report of this being different on glibc 2.11 and 2.13. We
// don't know when this change happened, so 2.14 is a conservative estimate.
#if __GLIBC_PREREQ(2, 14)
const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304);
#else
const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304);
#endif

We probably just have to fill in correct values for glibc 2.5.
>From gcc-bugs-return-442352-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 08:31:07 2014
Return-Path: <gcc-bugs-return-442352-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7184 invoked by alias); 3 Feb 2014 08:31:07 -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 7140 invoked by uid 48); 3 Feb 2014 08:31:04 -0000
From: "kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10
Date: Mon, 03 Feb 2014 08:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kcc at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-60038-4-yNKBuhhx4j@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60038-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60038-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: 2014-02/txt/msg00109.txt.bz2
Content-length: 401

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`038

--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
> GNU C Library stable release version 2.5

2.5 is way too old.
You may try to comment out this CHECK and see if the rest works
The main ASAN's functionality will probably not notice the lack of correct data
about TLS, but LSAN (LeakSanitizer) may start reporting false positives.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[kcc at gcc dot gnu.org]

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

--- Comment #5 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
> We probably just have to fill in correct values for glibc 2.5.
This may help. A patch is welcome, please check 
https://code.google.com/p/address-sanitizer/wiki/HowToContribute

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kostya Serebryany from comment #5)
> > We probably just have to fill in correct values for glibc 2.5.
> This may help. A patch is welcome, please check 
> https://code.google.com/p/address-sanitizer/wiki/HowToContribute

I have already gathered those values, but nothing happened since then, see
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00287.html

BTW, you could supposedly use
#include <unistd.h>
...
  char buf[64];
  size_t len = confstr (_CS_GNU_LIBC_VERSION, buf, sizeof buf);
  if (strncmp (buf, "glibc 2.", 8) == 0)
    {
      char *end;
      int minor = strtoul (buf + 8, &end, 10);
      if (end != buf + 8 && (*end == '\0' || *end == '.')
        {
          if (minor <= 3)

        }
    }

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
BTW, you could supposedly use
#include <unistd.h>
...
  char buf[64];
  size_t len = confstr (_CS_GNU_LIBC_VERSION, buf, sizeof buf);
  int result = 
  if (strncmp (buf, "glibc 2.", 8) == 0)
    {
      char *end;
      int minor = strtoul (buf + 8, &end, 10);
      if (end != buf + 8 && (*end == '\0' || *end == '.')
        {
          if (minor <= 3)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1104, 1696);
          else if (minor == 4)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1120, 1728);
          else if (minor == 5)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1136, 1728);
          else if (minor <= 9)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1136, 1712);
          else if (minor == 10)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 1776);
          else if (minor <= 12)
            kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2288);
          else
            kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304);
        }
    }

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[kcc at gcc dot gnu.org]

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

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
>   size_t len = confstr (_CS_GNU_LIBC_VERSION, buf, sizeof buf);
>   if (strncmp (buf, "glibc 2.", 8) == 0)

Yea, such patch is even more welcome. 
I was thinking about using __gnu_get_libc_version, 
to extract the libc version numbers, but confstr (_CS_GNU_LIBC_VERSION
sounds good too.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32021&action=edit
gcc49-pr60038.patch

This seems to work for me on glibc 2.17, Uros, can you please try it on your
CentOS 5?

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
Created attachment 32022
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32022&action=edit
Proposed patch

Jakub's solution from Comment #7 in the form of a patch.

Tested with RUNTESTFLAGS=asan.exp. The patch works for me on CentOS 5.10
without any problem.
>From gcc-bugs-return-442363-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 09:28:36 2014
Return-Path: <gcc-bugs-return-442363-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2681 invoked by alias); 3 Feb 2014 09:28:36 -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 2637 invoked by uid 48); 3 Feb 2014 09:28:32 -0000
From: "abel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537
Date: Mon, 03 Feb 2014 09:28: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: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: abel at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57915-4-80BUyEe0SC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57915-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57915-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: 2014-02/txt/msg00120.txt.bz2
Content-length: 696

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW915

--- Comment #9 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> I'd say if (plus:SI (symbol_ref:SI ...) (const_int ...)) not surrounded by
> (const:SI ) is considered invalid IL, then trying to workaround cprop bug in
> some other pass is still workaround rather than fix.

Sure, I agree that simplifying when inside cprop is the proper fix, though I
wasn't sure which of the general interfaces to fix.  The question of why fwprop
does not simplify this particular insn, i.e. whether the limitation of fwprop
working within loops makes sense, still remains IMHO, but this is a separate
issue.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 32021 [details]
> gcc49-pr60038.patch
> 
> This seems to work for me on glibc 2.17, Uros, can you please try it on your
> CentOS 5?

Uh, that was quick, I didn't noticed your submission. ;)

I'll test your patch in a moment.
>From gcc-bugs-return-442366-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 09:37:41 2014
Return-Path: <gcc-bugs-return-442366-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8114 invoked by alias); 3 Feb 2014 09:37: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 8056 invoked by uid 48); 3 Feb 2014 09:37:37 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
Date: Mon, 03 Feb 2014 09:37: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-60032-4-SfvT3lnlNj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60032-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60032-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: 2014-02/txt/msg00123.txt.bz2
Content-length: 290

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`032

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #9)
> > Created attachment 32021 [details]
> > gcc49-pr60038.patch
> > 
> > This seems to work for me on glibc 2.17, Uros, can you please try it on your
> > CentOS 5?
> 
> Uh, that was quick, I didn't noticed your submission. ;)
> 
> I'll test your patch in a moment.

sanitizer re-build and regression test with

RUNTESTFLAGS="--target_board=unix\{,-m32\} asan.exp"

worked without problems on CentOS 5.10.
>From gcc-bugs-return-442377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 10:24:31 2014
Return-Path: <gcc-bugs-return-442377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30587 invoked by alias); 3 Feb 2014 10:24:31 -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 30506 invoked by uid 48); 3 Feb 2014 10:24:26 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58742] pointer arithmetic simplification
Date: Mon, 03 Feb 2014 10:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58742-4-eqd6sfm5Ly@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58742-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58742-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: 2014-02/txt/msg00134.txt.bz2
Content-length: 2655

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX742

--- Comment #26 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> VERSION=0 and VERSION=1 are the same speed for me now,

They aren't quite for me (2.5 vs 2.7) but

> VERSION=2 is a lot slower still.

that's the part I am concerned with here.

> Yeah, the issue is that while FRE does some expression simplification it
> doesn't wire into a common gimple pattern matcher (something I'd like to
> fix for 4.10).  That is, the simplification forwprop performs should be
> done by FRE already.  See tree-ssa-sccvn.c:simplify_binary_expression.

Ah, ok, that makes sense. I assume it would also have basic CCP-like
functionality (forwprop can create constants but doesn't always fold the
resulting constant operations). Looking forward to that!

> > VRP2 is too late if we hope to vectorize, and in
> > any case it fails to remove the range checks, because it is confused by the
> > new shape of the loops (possibly related to PR 25643, or not). The VRP2
> > failure looks funny with these consecutive lines:
> >
> >   # ivtmp.80_92 = PHI <ivtmp.80_53(9), ivtmp.80_83(8)>
> >   # RANGE [10101, 989898] NONZERO 0x000000000000fffff
> >   _23 = ivtmp.80_92;
> >   if (ivtmp.80_92 > 999999)
> >
> > Really, we don't know that the comparison returns false?
>
> Well, _23 is simply dead at this point and VRP computed _92 to be
> varying.

Yes. I just meant that, as a hack, for 2 SSA_NAME defined in the same BB where
one is a copy of the other, we could merge their range info (in both
directions) and it might in this special case work around the fact that VRP2 is
confused by the loop. But that would be too fragile and hackish.

> From the no-undefined-overflow branch I'd take the idea of adding op
> variants with known no overflow.  That is, add MULTNV_EXPR, PLUSNV_EXPR,
> MINUSNV_EXPR that can be used on unsigned types, too (you'd of course
> have to define what overflow means there - if a - b does not overflow
> then a + (-b) will - negate of x will always overflow if x is not zero).

Ah, yes, I'd forgotten about those. I always wondered if it is better to have
many different tree codes or a single one with "options". Like MULT_EXPR with a
parameter saying what happens on overflow: undefined, saturate, wrap, other
(seems hard to handle "jump to this location" in the same). Or COMPARISON_EXPR
with several bools telling what the return value is if a<b, a==b, a>b, one is
NaN, and if it can raise exceptions (we don't have the corresponding 32 tree
codes). Or the 5 DIV_EXPR variants (counting only integers). I guess it doesn't
really matter.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 32021 [details]
> gcc49-pr60038.patch
> 
> This seems to work for me on glibc 2.17, Uros, can you please try it on your
> CentOS 5?

The patch was bootstrapped and regression tested OK [1] on CentOS 5.10.

[1] http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00160.html
>From gcc-bugs-return-442450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 03 21:39:39 2014
Return-Path: <gcc-bugs-return-442450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11873 invoked by alias); 3 Feb 2014 21:39:38 -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 11838 invoked by uid 48); 3 Feb 2014 21:39:34 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60041] Strange behavior
Date: Mon, 03 Feb 2014 21:39: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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 resolution
Message-ID: <bug-60041-4-SjcbIExyDF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60041-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60041-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: 2014-02/txt/msg00207.txt.bz2
Content-length: 508

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`041

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code is wildly undefined as the pointers are not initialized so closing as
invalid.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[kcc at gcc dot gnu.org]

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

--- Comment #14 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Landed upstream:
http://llvm.org/viewvc/llvm-project?view=revision&revision=200733
Note that the patch is slightly different from Jakub's: it uses
memory_order_relaxed.

My understanding is that now is not the best time to do full merge from
upstream,
so feel free to commit this patch to GCC separately.

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Feb  4 07:37:44 2014
New Revision: 207452

URL: http://gcc.gnu.org/viewcvs?rev=207452&root=gcc&view=rev
Log:
    PR sanitizer/60038
    * sanitizer_common/sanitizer_linux_libcdep.cc: Include
    sanitizer_atomic.h and unistd.h.
    (kThreadDescriptorSize): Made static, remove initializer and const,
    change type to atomic_uintptr_t.
    (ThreadDescriptorSize): Use confstr(_CS_GNU_LIBC_VERSION, ...) to
    query glibc version, compute kThreadDescriptorSize depending on
    glibc version minor number.
    (GetThreadStackAndTls): Use ThreadDescriptorSize() instead of
    kThreadDescriptorSize directly.

Modified:
    trunk/libsanitizer/ChangeLog
    trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

[Bug sanitizer/60038] AddressSanitizer CHECK failed ... "((*tls_addr + *tls_size)) <= ((*stk_addr + *stk_size))" on CentOS 5.10

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Hopefully fixed.