http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #19 from Yury Gribov ---
Paul, could you check if libsanitizer is now auto-disabled on your system and
close the bug in that case?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #18 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Thu Jan 23 14:32:05 2014
New Revision: 206966
URL: http://gcc.gnu.org/viewcvs?rev=206966&root=gcc&view=rev
Log:
2014-01-23 Yury Gribov
Jakub Jelinek
PR san
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #17 from Yury Gribov ---
Will do.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #16 from Jakub Jelinek ---
Sorry for not catching it earlier, I'm worried about -Wunused complaining about
the vars. Can you instead use something like
int x = syscall (__NR_gettid);
syscall (__NR_futex, &x, 1, 1);
syscall (__NR_exit_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Yury Gribov changed:
What|Removed |Added
Attachment #31917|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #14 from Jakub Jelinek ---
I wouldn't call the conditional SYSCALL_SUPPORTED, but SANITIZER_SUPPORTED or
so.
In the future, the configure could have various other reasons why it should
give up on building any sanitizer libraries altoge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Yury Gribov changed:
What|Removed |Added
Attachment #31916|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #12 from Jakub Jelinek ---
(In reply to Yury Gribov from comment #11)
> Created attachment 31916 [details]
> More robust check
>
> Does this look reasonable? Should also work for cross-builds.
1) these syscalls are only needed on Lin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #10 from Daniel Richard G. ---
(In reply to Richard Biener from comment #9)
> What's the status of this bug?
Same as I reported in comment #5---I just confirmed with a build of 4.8.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #7 from Daniel Richard G. ---
Created attachment 30723
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30723&action=edit
Trivial configure-time check
(In reply to Kostya Serebryany from comment #6)
>
> That would be non-trivial.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #6 from Kostya Serebryany ---
> Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
> pthread_mutex_*() be sensible here?
That would be non-trivial. We intercept the pthread_ functions so we can't
call them di
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Daniel Richard G. changed:
What|Removed |Added
CC||skunk at iskunk dot org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.8.1 |4.8.2
--- Comment #4 from Jakub Jelinek
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.1
Summary|[4.8 regression
17 matches
Mail list logo
