[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Note that the tests pass on x86_64-apple-darwin10 for both -m32 and -m64.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
On x86_64-apple-darwin11, at r204551, I only see the single failure of…

FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test

at both -m32 and -m64. More interestingly, if I compile the -m64 test case…

 /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c
 
-B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/

-L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/.libs
 -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never  
-O0  -fno-builtin-memset  -lm   -m64 -o ./global-overflow-1.exe 

, place it in the same directory as the libasan.1.dylib, libgcc_s.1.dylib and
libstdc++.6.dylib shared libraries and execute…

# setenv DYLD_LIBRARY_PATH .
# ./global-overflow-1.exe
=================================================================
==64301==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000102eaf1ea at pc 0x102eaed1c bp 0x7fff62aad740 sp 0x7fff62aad738
READ of size 1 at 0x000102eaf1ea thread T0
    #0 0x102eaed1b
(/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x100000d1b)
    #1 0x102eaec7f
(/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x100000c7f)
    #2 0x0
0x000102eaf1ea is located 0 bytes to the right of global variable 'YYY' from
'/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c'
(0x102eaf1e0) of size 10
0x000102eaf1ea is located 54 bytes to the left of global variable 'ZZZ' from
'/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c'
(0x102eaf220) of size 10
Shadow bytes around the buggy address:
  0x1000205d5de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e10: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x1000205d5e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000205d5e30: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9
  0x1000205d5e40: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000205d5e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==64301==ABORTING

it works as expected on darwin11. If I move this directory of files built under
darwin11 to a darwin12 machine, the same binaries produce the failure…

% setenv DYLD_LIBRARY_PATH .
% ./global-overflow-1.exe
==65680==AddressSanitizer CHECK failed:
../../../../gcc-4.9-20131107/libsanitizer/sanitizer_common/sanitizer_mac.cc:146
"((env_ptr)) != (0)" (0x0, 0x0)

My initial guess would be that the stricter ASLR could be in play but compiling
the test case with -Wl,-no_pie doesn't suppress the error on darwin12/13.
>From gcc-bugs-return-433901-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 08 04:13:24 2013
Return-Path: <gcc-bugs-return-433901-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9474 invoked by alias); 8 Nov 2013 04:13:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9392 invoked by uid 48); 8 Nov 2013 04:13:18 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561
Date: Fri, 08 Nov 2013 04:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59019-4-A3UyRtlTak@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59019-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59019-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00678.txt.bz2
Content-length: 727

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY019

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
Always considering trap-if as ending a BB appears to be a bit of a rathole.
Every time I squash one issue, another raises its head.

I did find that combine.c already has some bits to recognize when it does
something that may muck up the CFG and tries to compensate, it just doesn't
hadle the situation around trap-if.

I'm going to see if I can proof of concept a fix in that code.  Of course this
is a pass specific fix, but as I look deeper, more memories keep coming back --
we've had special code in cse.c to deal with similar situations, so maybe
adding another case for combine isn't that bad after all.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
Current llvm trunk is broken at the moment on darwin, but using a build from
Oct 29th, I have no issues with the failing test case under clang...

% /sw/opt/llvm-3.4/bin/clang -O1 -fsanitize=address -fno-builtin-memset -g
-fdiagnostics-color=never -O0 -m64 global-overflow-1.c
% ./a.out
=================================================================
==81836==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000103d991ea at pc 0x103d98b76 bp 0x7fff5be686d0 sp 0x7fff5be686c8
READ of size 1 at 0x000103d991ea thread T0
==81836==WARNING: Trying to symbolize code, but external symbolizer is not
initialized!
    #0 0x103d98b75 (/Users/howarth/./a.out+0x100001b75)
    #1 0x7fff8a4237e0 (/usr/lib/system/libdyld.dylib+0x27e0)
    #2 0x0

0x000103d991ea is located 54 bytes to the left of global variable 'main.ZZZ'
from 'global-overflow-1.c' (0x103d99220) of size 10
0x000103d991ea is located 0 bytes to the right of global variable 'main.YYY'
from 'global-overflow-1.c' (0x103d991e0) of size 10
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1000207b31e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b31f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3210: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000207b3220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000207b3230: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9
  0x1000207b3240: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000207b3250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==81836==ABORTING

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Jack Howarth from comment #4)
This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #6 from Alexander Potapenko <glider at google dot com> ---
The problem is caused by _NSGetEnviron() being called before libSystem is
initialized. This happens because some initialization code calls __cxa_atexit()
before libSystem_initialize(), and __cxa_atexit() calls __asan_init() and
_NSGetEnviron().

The fix is trivial (call the real __cxa_atexit() if asan_inited == 0 instead of
calling __asan_init()), but before landing it I'll check why the crash doesn't
happen on LLVM (I suspect different linkage order).

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #8 from Alexander Potapenko <glider at google dot com> ---
Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework.
When I remove that dependency, ASanified programs crash on the same env_ptr
assertion.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Alexander Potapenko from comment #8)
> Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation
> framework. When I remove that dependency, ASanified programs crash on the
> same env_ptr assertion.

Should we just add a CoreFoundation linkage to the creation of libasan.1.dylib
in FSF gcc instead?

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #10 from Alexander Potapenko <glider at google dot com> ---
This might help, but we don't actually need that dependency.
Instead libsanitizer should be updated to r194573.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Alexander Potapenko from comment #10)
> This might help, but we don't actually need that dependency.
> Instead libsanitizer should be updated to r194573.

Okay, I assume the missing linkage should be a trivial change like...

Index: libsanitizer/asan/Makefile.am
===================================================================
--- libsanitizer/asan/Makefile.am    (revision 204618)
+++ libsanitizer/asan/Makefile.am    (working copy)
@@ -43,7 +43,11 @@ libasan_la_LIBADD = $(top_builddir)/sani
 endif
 libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS)

+if USING_MAC_INTERPOSE
+libasan_la_LDFLAGS = -framework CoreFoundation -version-info `grep -v '^\#'
$(srcdir)/libtool-version` -lpthread -ldl
+else
 libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version`
-lpthread -ldl
+endif

 libasan_preinit.o: asan_preinit.o
     cp $< $@

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #12 from Alexander Potapenko <glider at google dot com> ---
That was Foundation, not sure if CoreFoundation also works.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Alexander Potapenko from comment #12)
> That was Foundation, not sure if CoreFoundation also works.

Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750
suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting
with -Wl,-framework,Foundation.

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #14 from Alexander Potapenko <glider at google dot com> ---
I think one of the frameworks depends on another one, please make sure to
pick the latter one if that's true.
Also add a comment denoting this is a dirty workaround.
On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
>
> --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> (In reply to Alexander Potapenko from comment #12)
> > That was Foundation, not sure if CoreFoundation also works.
>
> Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> r204750
> suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> Retesting
> with -Wl,-framework,Foundation.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Alexander Potapenko from comment #14)
> I think one of the frameworks depends on another one, please make sure to
> pick the latter one if that's true.
> Also add a comment denoting this is a dirty workaround.
> On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
> gcc-bugzilla@gcc.gnu.org> wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
> >
> > --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> > (In reply to Alexander Potapenko from comment #12)
> > > That was Foundation, not sure if CoreFoundation also works.
> >
> > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> > r204750
> > suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> > Retesting
> > with -Wl,-framework,Foundation.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> >

The Foundation framework is already linked against the CoreFoundation
framework. I've confirmed that linking libasan against
-Wl,-framework,Foundation alone (as is done by llvm) is sufficient to suppress
the asan.exp failures. This change will duplicate the linkage used by llvm for
the asan shared library. Posted proposed patch at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[glider at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #16 from Alexander Potapenko <glider at google dot com> ---
I've actually removed the Foundation linkage from LLVM today.
On Nov 13, 2013 10:45 PM, "howarth at nitro dot med.uc.edu" <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
>
> --- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> (In reply to Alexander Potapenko from comment #14)
> > I think one of the frameworks depends on another one, please make sure to
> > pick the latter one if that's true.
> > Also add a comment denoting this is a dirty workaround.
> > On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
> > gcc-bugzilla@gcc.gnu.org> wrote:
> >
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
> > >
> > > --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu>
> ---
> > > (In reply to Alexander Potapenko from comment #12)
> > > > That was Foundation, not sure if CoreFoundation also works.
> > >
> > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> > > r204750
> > > suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> > > Retesting
> > > with -Wl,-framework,Foundation.
> > >
> > > --
> > > You are receiving this mail because:
> > > You are on the CC list for the bug.
> > >
>
> The Foundation framework is already linked against the CoreFoundation
> framework. I've confirmed that linking libasan against
> -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to
> suppress
> the asan.exp failures. This change will duplicate the linkage used by llvm
> for
> the asan shared library. Posted proposed patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Alexander Potapenko from comment #16)
> I've actually removed the Foundation linkage from LLVM today.

Unfortunately, that is impossible to test here. A remerge of llvm libsanitizer
at 194597 with gcc trunk at r204752 bootstraps on x86_64-apple-darwin12 but
shows
lots of new test suite failures in asan.exp...

FAIL: c-c++-common/asan/global-overflow-1.c  -O0  output pattern test, is dyld:
Symbol not found: __ZN11__sanitizer10Symbolizer21symbolizer_allocator_E
  Referenced from:
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib
  Expected in: flat namespace
 in
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib
, should match READ of size 1 at 0x[0-9a-f]+ thread T0.*(
|
)    #0 0x[0-9a-f]+ (in _*main ([^
]*global-overflow-1.c:20|[^
]*:0)|[(])[^
]*(
|
).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^
]* of size 10[^
]*(
|
)

Shouldn't llvm's libsanitizer be better synced with FSF gcc's at this point?

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #18 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
Created attachment 31212
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31212&action=edit
fix from llvm svn

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Jack Howarth from comment #18)
> Created attachment 31212 [details]
> fix from llvm svn

The fix from llvm svn applied to gcc trunk at r204752 produces...

Native configuration is x86_64-apple-darwin12.5.0

        === g++ tests ===


Running target unix/-m32

        === g++ Summary for unix/-m32 ===

# of expected passes        481
# of unsupported tests        132

Running target unix/-m64

        === g++ Summary for unix/-m64 ===

# of expected passes        481
# of unsupported tests        132

        === g++ Summary ===

# of expected passes        962
# of unsupported tests        264
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ 
version 4.9.0 20131113 (experimental) (GCC) 

        === gcc tests ===


Running target unix/-m32

        === gcc Summary for unix/-m32 ===

# of expected passes        326
# of unsupported tests        101

Running target unix/-m64

        === gcc Summary for unix/-m64 ===

# of expected passes        326
# of unsupported tests        101

        === gcc Summary ===

# of expected passes        652
# of unsupported tests        202
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc  version 4.9.0
20131113 (experimental) (GCC) 

Compiler version: 4.9.0 20131113 (experimental) (GCC) 
Platform: x86_64-apple-darwin12.5.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.9/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9

for make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On x86_64-apple-darwin13 the fix from llvm svn applied to gcc trunk at r204759
produces...

Native configuration is x86_64-apple-darwin13.0.0

        === gcc tests ===

Running target unix/-m32

FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test <-- no error

        === gcc Summary for unix/-m32 ===

# of expected passes        324
# of unexpected failures    1
# of unsupported tests        101

Running target unix/-m64
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test <-- no error

        === gcc Summary for unix/-m64 ===

# of expected passes        324
# of unexpected failures    1
# of unsupported tests        101

        === gcc Summary ===

# of expected passes        648
# of unexpected failures    2
# of unsupported tests        202

        === g++ tests ===

Running target unix/-m32

        === g++ Summary for unix/-m32 ===

# of expected passes        481
# of unsupported tests        132

Running target unix/-m64

        === g++ Summary for unix/-m64 ===

# of expected passes        481
# of unsupported tests        132

        === g++ Summary ===

# of expected passes        962
# of unsupported tests        264

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

--- Comment #21 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Author: kcc
Date: Fri Nov 15 10:31:14 2013
New Revision: 204838

URL: http://gcc.gnu.org/viewcvs?rev=204838&root=gcc&view=rev
Log:
fix PR sanitizer/58994

Modified:
    trunk/libsanitizer/ChangeLog
    trunk/libsanitizer/asan/asan_interceptors.cc

[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #22 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
Verified as fixed at r204847 on x86_64-apple-darwin13.