Hi,
FAIL: g++.dg/tsan/default_options.C -O2 execution test
Both these tests don't report anything (well, default_options.C
prints DONE),
simply succeed (with dg-shouldfail that is a failure)
I've finally fixed g+.dg/tsan/default_options.C test (the check
dg-shouldfail should be
On Tue, Feb 04, 2014 at 06:44:22PM +0400, Maxim Ostapenko wrote:
Hi,
FAIL: g++.dg/tsan/default_options.C -O2 execution test
Both these tests don't report anything (well, default_options.C
prints DONE),
simply succeed (with dg-shouldfail that is a failure)
I've finally fixed
Commited in 207472.
-Maxim
I've started a separate topic about flaky tsan tests here:
https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
On Fri, Jan 10, 2014 at
FAIL: g++.dg/tsan/default_options.C -O2 execution test
This one looks plain wrong to me. It should be checked for success
instead of failure.
-Y
Uros Bizjak wrote:
The same tsan failures are reported in one of HJ's testers [2], with message:
Can this be duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 ?
-Y
On Fri, Jan 10, 2014 at 10:23:59AM +0100, Uros Bizjak wrote:
I was able to compile sanitizer with r206475 (after Jakub's fixes) and
run the testsuite. However, on 64bit target, I got some failures in
asan and several timeouts in tsan [1].
Some of the tsan tests seems to FAIL randomly for quite
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 10, 2014 at 10:23:59AM +0100, Uros Bizjak wrote:
I was able to compile sanitizer with r206475 (after Jakub's fixes) and
run the testsuite. However, on 64bit target, I got some failures in
asan and several
Hi all,
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinekja...@redhat.com wrote:
Some of the tsan tests seems to FAIL randomly for quite a while
(since they were added), didn't have time to look if it is just bugs
in the test or
some compiler issue or library issue.
When I've commited
On Fri, Jan 10, 2014 at 10:23 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak ubiz...@gmail.com wrote:
Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a
On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinekja...@redhat.com wrote:
Some of the tsan tests seems to FAIL randomly for quite a while
(since they were added), didn't have time to look if it is just
bugs in the test or
On Wed, Dec 4, 2013 at 5:47 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor i...@google.com wrote:
On Wed, Dec 4, 2013 at 8:04 AM, FX fxcoud...@gmail.com wrote:
Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
Well,
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
Expected ChangeLog entries:
=== libsanitizer/ChangeLog
2013-12-0X Kostya Serebryany k...@google.com
* All source files: Merge from upstream r196090.
* tsan/Makefile.am (tsan_files): Added new
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law l...@redhat.com wrote:
On 12/03/13 22:08, Konstantin Serebryany wrote:
We need
a) patches that we can review and apply to the llvm repository (w/o
breaking the modern systems, of course)
b) a buildbot that would run 24/7 catching regressions.
If we
On Thu, Dec 5, 2013 at 4:22 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law l...@redhat.com wrote:
On 12/03/13 22:08, Konstantin Serebryany wrote:
We need
a) patches that we can review and apply to the llvm repository (w/o
breaking
The kernel and glibc check should be done at the toplevel.
So what are the minimum kernel and glibc we want to
support?
For us, the versions we want to support are those that have green
upstream buildbots and someone to keep them green.
It's hard or impossible to set a more precise combination
On Wed, Dec 04, 2013 at 06:28:31AM +0100, Konstantin Serebryany wrote:
We don't have any .cfi stuff in sanitizer_common (and I don't think we
really need it in the internal_clone).
Before fixing the tsan sources I'd like to see some indication that
anyone cares about tsan working on older
Of course various parties care about that. But that doesn't necessarily
imply they can or want to run buildbots for a different compiler they don't
care about, there are e.g. security implications to that, resources etc.
This brings us back to the initial issue: the way asanco are developed.
On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
I would start from kernel version and glibc version, this should cover
the majority of use cases.
Well, for the kernel headers what we perhaps can do is just add
libsanitizer/include/linux/ tree that will be maintained by
On Wed, Dec 4, 2013 at 5:02 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
I would start from kernel version and glibc version, this should cover
the majority of use cases.
Well, for the kernel headers what we perhaps can do is
On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
Well, for the kernel headers what we perhaps can do is just add
libsanitizer/include/linux/ tree that will be maintained by GCC and will
if that works for you, no objections.
I haven't tried to do that yet, so don't
On Wed, Dec 4, 2013 at 5:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
Well, for the kernel headers what we perhaps can do is just add
libsanitizer/include/linux/ tree that will be maintained by GCC and will
if that works
Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
care about regressions in your code, it makes little sense for GCC (the whole
project) to keep libsanitizer.
I’ve posted this
On Wed, Dec 4, 2013 at 8:04 AM, FX fxcoud...@gmail.com wrote:
Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
care about regressions in your code, it makes little sense for GCC
I believe this is a case where the GCC project gets more benefit from
libsanitizer than libsanitizer gets from being part of the GCC
project. We should work with the libsanitizer developers to make this
work, not just push everything back on them.
You’re vastly better qualified than me to
On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor i...@google.com wrote:
On Wed, Dec 4, 2013 at 8:04 AM, FX fxcoud...@gmail.com wrote:
Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
Well, you’re one of the maintainers of libsanitizer for GCC, so if you do
I think libsanitizer should be disabled automatically if kernel or glibc are
too old.
I think pretty much everyone agrees. But noone’s willing to put forward a
patch, and so far the libsanitizer maintainers have failed to even document the
requirements. (There are also binutils requirements,
On Wed, Dec 4, 2013 at 8:50 AM, FX fxcoud...@gmail.com wrote:
I think libsanitizer should be disabled automatically if kernel or glibc are
too old.
I think pretty much everyone agrees. But noone’s willing to put forward a
patch,
What are the agreed-upon minimum kernel and glibc? I
can give
On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
I believe this is a case where the GCC project gets more benefit from
libsanitizer than libsanitizer gets from being part of the GCC
project. We should work with the libsanitizer developers to make this
work, not just push
On Wed, Dec 4, 2013 at 8:58 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
I believe this is a case where the GCC project gets more benefit from
libsanitizer than libsanitizer gets from being part of the GCC
project. We should work with
On Wed, 4 Dec 2013, H.J. Lu wrote:
The kernel and glibc check should be done at the toplevel.
So what are the minimum kernel and glibc we want to
support?
Checking those at toplevel is tricky in general because you're checking
something for the target rather than the host. You'd need to
On 12/03/13 22:28, Konstantin Serebryany wrote:
I really think that we need to disable libsanitizer on old systems
until someone volunteers to set up a proper testing process upstream.
If no one volunteers -- no one really needs it.
The right way to do this is to do feature tests rather than
On 12/03/13 22:08, Konstantin Serebryany wrote:
We need
a) patches that we can review and apply to the llvm repository (w/o
breaking the modern systems, of course)
b) a buildbot that would run 24/7 catching regressions.
If we reach a green state for a platform X and have a buildbot for it,
On Wed, Dec 4, 2013 at 9:28 AM, Joseph S. Myers jos...@codesourcery.com wrote:
On Wed, 4 Dec 2013, H.J. Lu wrote:
The kernel and glibc check should be done at the toplevel.
So what are the minimum kernel and glibc we want to
support?
Checking those at toplevel is tricky in general because
On Wed, Dec 4, 2013 at 8:58 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
I believe this is a case where the GCC project gets more benefit from
libsanitizer than libsanitizer gets from being part of the GCC
project. We should work with
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Ok, so this does not gate
On Tue, Dec 3, 2013 at 3:50 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Ok, so this does not
On 12/03/13 08:47, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
==2738==AddressSanitizer CHECK failed:
../../../../libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:260
((*tls_addr + *tls_size)) = ((*stk_addr + *stk_size)) (0x2af8df1bc240,
0x2af8df1bc000)
which clearly is
This won't happen any time soon, right?
I'd like to ask glibc for many other things, not just this, but the
latency
of the glibc changes propagating to users is too low, so we don't
bother (although we should)
E.g. we've been hit by the ugly
pthread_getattr_np/pthread_attr_getstack
On Tue, Dec 3, 2013 at 5:42 PM, Jeff Law l...@redhat.com wrote:
On 12/03/13 08:47, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of
On Mon, Dec 2, 2013 at 11:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
with #if LINUX_VERSION_CODE = 132640
Good idea, let me try that.
Had a quick look at this on RHEL 5.
Following patch let me compile at least the
On Mon, Dec 2, 2013 at 3:52 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Another libsanitizer merge from upstream, r196090
(needs attention on ubsan side)
This hopefully fixes various build failures on non-x86-linux platforms,
although I still tested it only on our
On Mon, Dec 02, 2013 at 05:13:45AM -0800, H.J. Lu wrote:
=== libsanitizer/ChangeLog
2013-12-0X Kostya Serebryany k...@google.com
* All source files: Merge from upstream r196090.
* tsan/Makefile.am (tsan_files): Added new files.
* tsan/Makefile.in:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0 execution test
I am asking gcc-ubsan maintainers to help me decipher
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp'
FAIL: c-c++-common/ubsan/vla-1.c -O0
On Mon, Dec 2, 2013 at 6:41 PM, Marek Polacek pola...@redhat.com wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan test:
make check -C gcc
On Mon, Dec 02, 2013 at 03:47:18PM +0100, Jakub Jelinek wrote:
On Mon, Dec 02, 2013 at 03:41:18PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
This change breaks one ubsan
Hello!
Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a matter of follow-up patch
with configury/Makefile etc. stuff, I'll work on it once the merge is
committed.
What is more important
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a matter of follow-up patch
with configury/Makefile etc. stuff,
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so hopefully it will be just a matter of follow-up patch
with
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Does it support using libbacktrace in GCC?
Not on it's own, but the support in the upstream maintained files
is there, so
On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
We can fix this particular failure, but unless someone helps us test
the code upstream
(not just that it builds, but also that it works) asan has little
chance to work on old systems anyway.
For these kernel headers that
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer
On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
No, so your patch doesn't regress anything. I can configure with
--disable-libsanitizer to skip build of libsanitizer, although it
would be nice to support RHEL5 derived long-term distributions.
Is there a way to test gcc in such
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
with #if LINUX_VERSION_CODE = 132640
Good idea, let me try that.
Had a quick look at this on RHEL 5.
Following patch let me compile at least the first source file, but then
I run into tons of issues in
On Tue, Dec 3, 2013 at 2:32 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
with #if LINUX_VERSION_CODE = 132640
Good idea, let me try that.
Had a quick look at this on RHEL 5.
Following patch let me compile at least the first
On Tue, Dec 3, 2013 at 6:53 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
with #if LINUX_VERSION_CODE = 132640
Good idea, let me try that.
Had a quick look at this on RHEL 5.
Following patch let me compile at least the first source file, but then
I run into tons of
61 matches
Mail list logo
