Commited in 207472.
-Maxim
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 finall
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 remo
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
> 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
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 wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jaku
On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
> On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek 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 compil
On Fri, Jan 10, 2014 at 10:23 AM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak 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 pa
Hi all,
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek 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 these tsan tests,
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek 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 timeouts in tsa
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 qui
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak 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 configury/Makefile etc. stuff, I'll work on it on
> 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 combinati
On Thu, Dec 5, 2013 at 4:22 PM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law 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)
>>>
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law 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 r
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> Expected ChangeLog entries:
> === libsanitizer/ChangeLog
>
> 2013-12-0X Kostya Serebryany
>
> * All source files: Merge from upstream r196090.
> * tsan/Makefile.am (tsan_files): Added new files.
>
On Wed, Dec 4, 2013 at 5:47 PM, H.J. Lu wrote:
> On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor wrote:
>> On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
> Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
>>>
>>>
>>> Well, you’re one of the maintainers
On Wed, Dec 4, 2013 at 8:58 PM, Jakub Jelinek 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 the libs
On Wed, Dec 4, 2013 at 9:28 AM, Joseph S. Myers 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 you're checking
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,
keepi
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 jus
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 m
On Wed, Dec 4, 2013 at 8:58 AM, Jakub Jelinek 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 the libs
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 ev
On Wed, Dec 4, 2013 at 8:50 AM, FX 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 it a try.
>
> 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:41 AM, Ian Lance Taylor wrote:
> On Wed, Dec 4, 2013 at 8:04 AM, FX 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
> 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:04 AM, FX 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 (the whol
> > 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 5:44 PM, Jakub Jelinek 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 for y
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'
On Wed, Dec 4, 2013 at 5:02 PM, Jakub Jelinek 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 just add
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 G
> 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 asan&co are develope
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 s
On Mon, Dec 2, 2013 at 11:32 PM, Jakub Jelinek 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 sour
On Tue, Dec 3, 2013 at 5:42 PM, Jeff Law 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 libsa
>>>
>>> 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/pthrea
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)
> > whic
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 distr
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
On Tue, Dec 3, 2013 at 3:50 PM, Jakub Jelinek 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 support R
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 no
On Tue, Dec 3, 2013 at 6:53 AM, 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 sanitizer_
On Tue, Dec 3, 2013 at 2:32 AM, Jakub Jelinek 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 sourc
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 sanitizer_platfor
On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
> On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek 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 b
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek 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 derived lon
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 tha
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
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
> 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 o
On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
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 configury/Makefile etc. stuff, I'l
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak 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, I'll wor
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 impo
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
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 RUNTESTFLAGS='--target_board=un
On Mon, Dec 2, 2013 at 6:41 PM, 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 RUNTESTFLAGS='--target_board=unix\{-m32,-m6
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 e
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 d
On Mon, Dec 02, 2013 at 05:13:45AM -0800, H.J. Lu wrote:
> > === libsanitizer/ChangeLog
> >
> > 2013-12-0X Kostya Serebryany
> >
> > * All source files: Merge from upstream r196090.
> > * tsan/Makefile.am (tsan_files): Added new files.
> > * tsan/Makefile.in: Rege
On Mon, Dec 2, 2013 at 3:52 AM, Konstantin Serebryany
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 x86_64 Linux Ubuntu 12.04 box:
> r
62 matches
Mail list logo
