http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
Summary: Unsafe double checked locking in __emutls_get_address
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80839
Evgeniy Stepanov changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80839
--- Comment #2 from Evgeniy Stepanov ---
Hmm, where is the button to mark this resolved/wontfix?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
Bug #: 55981
Summary: std::atomic store is split in two smaller stores
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
--- Comment #1 from Evgeniy Stepanov
2013-01-14 22:45:30 UTC ---
Disassembly of the loop in ff() function:
4007c0: movl $0x2,0x2008de(%rip)# 6010a8
4007ca: movl $0x1,0x2008d8(%rip)# 6010ac
4007d4:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
--- Comment #2 from Evgeniy Stepanov
2013-01-14 22:48:08 UTC ---
Btw, the same happens if atomic is replaced with "volatile unsigned long y" -
which does not violate the standard, but may be considered undesirable by some.
I don't have a s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #3 from Evgeniy Stepanov
2013-01-18 11:57:07 UTC ---
(In reply to comment #2)
> See 1.9p8 of the C++11 standard, first bullet:
>
> "Access to volatile objects are evaluated strictly according to the rules of
> the abstract m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
--- Comment #5 from Evgeniy Stepanov
2013-01-18 16:38:11 UTC ---
Well, it's true that classes have assignment operators, and basic types don't.
But this does not have anything to do with how the assignment could (or could
not) be implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Evgeniy Stepanov changed:
What|Removed |Added
CC||eugeni.stepanov at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #11 from Evgeniy Stepanov
2013-02-20 14:57:02 UTC ---
Yes, dynamic libasan is still busted.
We could link a small .o into executables built with dynamic libasan; that .o
would contain a .preinit record pointing to the dynamical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #13 from Evgeniy Stepanov
2013-02-20 18:29:57 UTC ---
I don't see what can be done in that case. We should just declare it
unsupported.
We've got this problem on Android, where an instrumented JNI library is loaded
into Dalv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
--- Comment #16 from Evgeniy Stepanov
2013-02-21 11:51:17 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > We've got this problem on Android, where an instrumented JNI library is
> > loaded
> > into Dalvik VM, which is o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
--- Comment #2 from Evgeniy Stepanov ---
As discussed in a email thread on gcc-patches, we will probably move away from
including kernel headers and just define all the types in our code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #2 from Evgeniy Stepanov ---
Weak symbols. Ouch.
We should link with libasan with librt. In Clang, we add -lrt to the linker
flags when we see -fsanitize=(address|thread|memory).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #11 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > I think in newer versions of glibc, clock_gettime is in libc.so now too.
>
> I think Andrew is right - clock_get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #15 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #13)
> (In reply to Evgeniy Stepanov from comment #11)
> > (In reply to Yury Gribov from comment #4)
> > > Evgeniy, what about a warning in GetRealFunctionAddress if r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #8 from Evgeniy Stepanov ---
I'm a little surprised we did not run into this on Android yet - we use the
same LD_PRELOAD scheme there. Are you linking libasan with libpthread? This
might go away as libpthread constructors call one of t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #10 from Evgeniy Stepanov ---
We don't intercept signal() on Android, because there is a friendly crash
handler installed by the OS, and we don't need to handle segv ourselves.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #17 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #16)
> (In reply to Evgeniy Stepanov from comment #15)
> > No need, I'm fixing it now.
>
> Sorry for bothering but is this in compiler-rt trunk yet?
Sorry, I forgot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #13 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #12)
> (In reply to Evgeniy Stepanov from comment #8)
> > ... one of the ASan interceptors
> > that does ENSURE_ASAN_INITED().
> > Arguably, all interceptors should do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
--- Comment #15 from Evgeniy Stepanov ---
In fact, a recent change disabled ASAN_FLEXIBLE_MAPPING_AND_OFFSET and killed
all supporting code. Or are you talking about a different change?
ASAN_FLEXIBLE_MAPPING_AND_OFFSET indeed prevents LD_PRELOAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #20 from Evgeniy Stepanov ---
I can confirm that the issue can be reproduced on 3.13.0-5-generic (ubuntu
14.04 candidate), and can not be reproduced on 3.11.0-15-generic (ubuntu
13.10).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #21 from Evgeniy Stepanov ---
A reproducer without ASan:
#include
#include
#include
#include
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i < 100; ++i)
mmap(p + i * 4096, 4096, PROT_WRITE | PROT_READ, MAP
Assignee: unassigned at gcc dot gnu.org
Reporter: eugeni.stepanov at gmail dot com
Created attachment 32301
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32301&action=edit
proof
==26761== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f2c4996
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456
Evgeniy Stepanov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eugeni.stepanov at gmail dot com
Created attachment 32339
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32339&action=edit
source code
At r208400, GCC is faili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
--- Comment #3 from Evgeniy Stepanov ---
Yes, FP on ARM is non-standard and differs in GCC and Clang implementations.
Disabling fast unwind is not really an option, as you are looking at 10x, maybe
100x slowdown (depending of the app, of course).
27 matches
Mail list logo
