[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug other/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:50:09 UTC --- [The component for such bugs should be 'sanitizer' but for some reason I can't change it]

[Bug sanitizer/55517] [ASAN] ASAN doesn't work with (soft) ulimit on virtual memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55517 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-28 12:56:53 UTC --- We try to minimize the number of syscalls we make in asan run-time. One reason for that is that asan may run in a sanbox which

[Bug sanitizer/55488] New: Implement cold calls in tsan run-time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488 Bug #: 55488 Summary: Implement cold calls in tsan run-time Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug sanitizer/55485] probable false positive on __builtin_setjmp/__builtin_longjmp

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55485 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-27 17:52:02 UTC --- For what purpose would any one avoid longjmp call, other than for performance? Under asan, performance already drops by 2x, so

[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #27 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 10:47:14 UTC --- is it really so crucial that you'd want to make another libtsan_pie.a for it? I would actually prefer to have *only

[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 10:56:44 UTC --- Not that today's upstream tsan sources don't link with -fPIC at all because our assembly blobs are not PIC-friendly. /usr/bin

[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #28 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 11:14:58 UTC --- Note that today's upstream tsan sources don't link with -fPIC at all because our assembly blobs are not PIC-friendly. /usr

[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #10 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-23 12:44:14 UTC --- libsanitizer/README.gcc was updated, and libsanitizer/merge.sh was create to help with merges.

[Bug sanitizer/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added Status|NEW

[Bug other/55435] New: [asan] implement an attribute to disable asan instrumentation for a particular function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55435 Bug #: 55435 Summary: [asan] implement an attribute to disable asan instrumentation for a particular function Classification: Unclassified Product: gcc Version: unknown

[Bug other/55410] New: [asan] bit field accesses are not instrumented

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55410 Bug #: 55410 Summary: [asan] bit field accesses are not instrumented Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #8 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-21 04:23:21 UTC --- Why do you want to bother with a ChangeLog? I don't. I would prefer to simply mention the upstream revision to which

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #15 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 09:03:35 UTC --- You are right that -fPIC -ftls-model=initial-exec does not affect performance if we link libtsan statically (I checked

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #16 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 09:06:26 UTC --- So, using -fPIC -ftls-model=initial-exec is a great idea, it will allow to build the files once and have both static

[Bug other/55333] libsanitizer StackTrace::FastUnwindStack wrong x32

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55333 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-20 05:40:34 UTC --- Merging in both directions is possible, but painful, so I'd prefer to limit it. How about this phrasing? === All changes

[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 --- Comment #5 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-20 05:46:06 UTC --- Then it should probably *not* be named _ADDRESS_SANITIZER (imagine a user trying to understand why ADDRESS_SANITIZER works

[Bug other/55376] [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 --- Comment #3 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 18:47:19 UTC --- Are all upstream changes considered reviewed and automatically approved for gcc repo? all upstream changes are pre- or post

[Bug driver/55379] -static -static-libasan pass -Bdynamic to linker

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #9 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 19:35:43 UTC --- As dvyuokv@ pointed out, -ftls-model=initial-exec improves the situation, but does not fully help. Experiment: % cat x.c

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #11 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-18 19:59:42 UTC --- The above comment is correct. -fPIE is only applicable if we build libtsan.a and link it statically to the pie executable

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #13 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-19 04:13:23 UTC --- of course everything would need to be done only given appropriate benchmarks of real-world programs. We have a synthetic

[Bug other/55353] [asan] the flag for asan should match the one used in clang

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug other/55376] New: [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376 Bug #: 55376 Summary: [asan] libsanitizer/README.gcc must contain the exact steps to do code changes and to port code from upstream Classification: Unclassified

[Bug other/55353] New: [asan] the flag for asan should match the one used in clang

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Bug #: 55353 Summary: [asan] the flag for asan should match the one used in clang Classification: Unclassified Product: gcc Version: unknown Status:

[Bug other/55354] New: [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 Bug #: 55354 Summary: [asan] by default, the asan run-time should be linked statically, not dynamically Classification: Unclassified Product: gcc Version: unknown

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-16 20:28:34 UTC --- You have been warned (especially about tsan performance. tsan run-time heavily depends on TLS, and TLS is much slower with -fPIC

[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #6 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-16 20:54:40 UTC --- Answering my own question: we can get static linking with -Wl,-Bstatic -lasan -Wl,-Bdynamic -ldl -lpthread For TLS, you

[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #32 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-14 20:21:19 UTC --- Just want to repeat, that any work on mach_override may end up being wasted time because we plan to get rid of mach_override

[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #35 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-14 23:10:00 UTC --- Is that certain to be soon enough Not 100%. I am just warning you. Will the replacement of mach_override also depend

[Bug other/55309] gcc's address-sanitizer 66% slower than clang's

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug bootstrap/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Konstantin Serebryany konstantin.s.serebryany at gmail dot com changed: What|Removed |Added CC

[Bug rtl-optimization/52629] New: global buffer overflow in gcc/reload1.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52629 Bug #: 52629 Summary: global buffer overflow in gcc/reload1.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: