https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315
--- Comment #9 from Jack Howarth ---
(In reply to Andrew Pinski from comment #8)
> > Is the object here to burn all bridges with the darwin target and leave
> > those users only the option of using llvm based compilers as of gcc 4.10?
>
> Well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315
--- Comment #6 from Jack Howarth ---
I would also add that you are playing with fire here. Currently no company has
a motivation to expend money or resources for fortran development on llvm as
long as FSF gcc is buildable. If you start removing c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #5 from Jack Howarth ---
Added preprocessed source and assembly file generated with...
/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-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #3 from Jack Howarth ---
Created attachment 31451
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31451&action=edit
preprocessed source for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #4 from Jack Howarth ---
Created attachment 31452
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31452&action=edit
assembly file for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #12 from Jack Howarth ---
Added Jeff Law since he reviewed and approved the offending patch.
onent: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
The bootstrap of current gcc trunk on x86_64-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #4 from Jack Howarth ---
(In reply to Jack Howarth from comment #3)
> /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1
> /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine
> -fcheck-references -fuse-boehm-gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
--- Comment #3 from Jack Howarth ---
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1
/var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine
-fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions
-f
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
Current gcc trunk at r205857 fails to bootstrap on x86_64-apple-darwin12
using...
../gcc-4.9-20131210/configure --prefix=/sw --prefix=/sw/lib/gcc4.9
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369
--- Comment #1 from Jack Howarth ---
From
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x,
the following code would work on darwin, but I'm not sure if the test is still
valid...
/* { dg-do run } */
#ifdef __MACH_
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
The new c-c++-common/asan/pr59063-1.c and c
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
The new gcc.dg/atomic/c11-atomic-exec-5.c execution test fails on
x86_64-apple-darwin13 for all optimization levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148
--- Comment #6 from Jack Howarth ---
(In reply to Alexander Potapenko from comment #3)
> GCC emits calls to __strcpy_chk and __strncpy_chk in this test, which
> happens because of source fortification being on by default on Darwin.
> In Clang we'r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148
--- Comment #2 from Jack Howarth ---
Also confirmed that if you compile the failing test case using current
llvm/clang svn with...
/sw/opt/llvm-3.4/bin/clang -fsanitize=address -g -fdiagnostics-color=never -O0
-fno-builtin-malloc -fno-builtin-str
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
Jack Howarth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #19 from Jack Howarth ---
(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-dar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #18 from Jack Howarth ---
Created attachment 31212
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31212&action=edit
fix from llvm svn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #17 from Jack Howarth ---
(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
ting this is a dirty workaround.
> On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
> >
> > --- Comment #13 from Jack Howarth ---
> > (In reply to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #13 from Jack Howarth ---
(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 o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #11 from Jack Howarth ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #9 from Jack Howarth ---
(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_pt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892
--- Comment #4 from Jack Howarth ---
(In reply to Andrew Pinski from comment #3)
> Bug in the compiler originally used so closing as invalid.
Just to note that Apple finally back ported the llvm-gcc bug fix in Xcode 4.6.1
or later upon their swit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #5 from Jack Howarth ---
(In reply to Jack Howarth from comment #4)
This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #4 from Jack Howarth ---
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-builti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #3 from Jack Howarth ---
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
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
Currently gcc trunk breaks the build of the dragonegg 3.4svn plugin with the
error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097
--- Comment #11 from Jack Howarth ---
(In reply to Iain Sandoe from comment #10)
>
> what's the expectation/status here?
>
> I see that these test-cases still fail on x86_64-darwin12, with the latest
> XCode tools.
These failures are still pres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #24 from Jack Howarth ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
>
> http://opensource.apple.com/tarballs/libunwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
--- Comment #20 from Jack Howarth ---
(In reply to Iain Sandoe from comment #19)
The full commit where this was added to llvm is at
http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/153081 and references
http://software.intel.com/en-us/int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #20 from Jack Howarth ---
(In reply to Iain Sandoe from comment #19)
Yes. It might be a more profitable use of time to work on moving from the
compatibility unwinder onto the newer compact unwinder for modern darwin.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
After switching my normal gcc48 packaging build to use lean bootstraps, I
noticed a number of test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #7 from Jack Howarth ---
(In reply to Jack Howarth from comment #6)
My mistake in mixing host_configargs and build_configargs. The following patch
works fine…
Index: configure.ac
===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #6 from Jack Howarth ---
(In reply to Jack Howarth from comment #5)
The same change of adding --with-sysroot=\"`xcrun --show-sdk-path`\" to
build_configargs also fails when fix_includes tries to find /usr/include.
Strangely, adding --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #5 from Jack Howarth ---
I am really surprised the following change if insufficient to replace manually
passing…
--with-sysroot="`xcrun --show-sdk-path`"
to configure on the command line for darwin13...
Index: configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Jack Howarth changed:
What|Removed |Added
Summary|fixincludes doesn't honor |toplevel configure should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #3 from Jack Howarth ---
(In reply to Bruce Korb from comment #2)
> Paolo did the config stuff, with Kaveh's help.
> However, Jack Howarth may be in a better position to
> make a patch since I do not have an Apple development
> system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Jack Howarth changed:
What|Removed |Added
Summary|--with-native-system-header |fixincludes doesn't honor
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
The removal of the SDK from / (i.e. no /usr/include or
/System/Library/Frameworks/*.framework/Headers directories) breaks the
fixincludes step of the bootstrap on darwin. The only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #4 from Jack Howarth ---
Actually, FSF gcc doesn't know about the SDKROOT path that xcrun sets. A change
similar to…
http://permalink.gmane.org/gmane.comp.compilers.clang.scm/56103
needs to be implemented on darwin so that FSF checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #2 from Jack Howarth ---
Okay, the bootstrap without headers outside of the SDK can be simplified on
darwin to…
./configure -with-native-system-header-dir=`xcrun --show-sdk-path`/usr/include
CXX_FOR_BUILD="xcrun g++" CC_FOR_BUILD="xcr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #1 from Jack Howarth ---
I should also note that removal of SDK from / isn't as bad as it sounds. In
general, most builds can puzzle out the location of the necessary headers.
However, FSF gcc is a complex build (especially regarding t
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
The WWDC "What’s New in the LLVM Compiler" video on
https://developer.apple.com/wwdc/videos/ indicated that the SDK will be moved
out of /
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #18 from Jack Howarth ---
Do we have any idea why this problem is latent with --checking=release and
--checking=yes but is triggered by --disable-checking?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #8 from Jack Howarth ---
The darwin linker developer's analysis of the failing linkage of cc1 is
below...
The assertion is about the file libbackend.a(varasm.o). There are overlapping
FDEs. If you run dwarfdump in verify mode, it wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #6 from Jack Howarth ---
I've opened radar://14005298, "linker crash when building FSF gcc with
--disable-checking" with a standalone test case of the failing linkage of cc1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #3 from Jack Howarth ---
The trigger for this bug is the use of --disable-checking. The linker crash
doesn't occur when --enable-checking=release or --enable-checking=yes is passed
to configure instead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57424
--- Comment #1 from Jack Howarth ---
This problem is caused by following change in gcc trunk. In gcc-4_8-branch, the
generated Makefile in darwin_objdir/x86_64-apple-darwin12.3.0/i386/libjava/gcj
has...
dbexecdir = $(libdir)/i386/gcj-4.8.1-14
wh
: java
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at nitro dot med.uc.edu
At r199345, on x86_64-apple-darwin12, I am finding that installation
subdirectory for the multilib of gcj-4.9.0-14 is now installed in...
/sw/src/fink.build/root-gcc49-4.9.0-1000/sw/lib/gcc4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835
--- Comment #5 from Jack Howarth 2013-04-09
22:57:00 UTC ---
This has been filed with MacPorts as https://trac.macports.org/ticket/38732
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835
--- Comment #4 from Jack Howarth 2013-04-09
22:55:27 UTC ---
IMHO, this should be closed as invalid since MacPorts is applying unnecessary
and invalid patches to gcc 4.8.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56721
--- Comment #2 from Jack Howarth 2013-03-25
14:24:55 UTC ---
Will http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00853.html go into both gcc
4.9 and 4.8.1?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56721
Bug #: 56721
Summary: libffi.info installed in share/info collides with that
from libffi itself
Classification: Unclassified
Product: gcc
Version: 4.8.0
Sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407
--- Comment #18 from Jack Howarth 2013-03-11
14:51:01 UTC ---
(In reply to comment #17)
> Jack,
>
> I see at http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00331.html that you
> have tested a fix for this PR. I have tested that it ski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #17 from Jack Howarth 2013-03-05
22:20:33 UTC ---
(In reply to comment #16)
> If it's easier to just disable the dg-final, that's fine too.
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00210.html. Can
you com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #15 from Jack Howarth 2013-03-05
16:55:07 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > What is supposed to be tested? Should the whole test skipped on darwin or
> > only
> > the dg-final?
>
> The whole
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #12 from Jack Howarth 2013-03-05
15:01:55 UTC ---
(In reply to comment #11)
> It seems that darwin doesn't do PIC the way ELF targets do, so this test
> should
> be skipped.
I also confirmed this with stock gcc trunk (to ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #10 from Jack Howarth 2013-03-05
13:48:03 UTC ---
Created attachment 29584
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29584
m32 thunk1.s -std=gnu++98 on x86_64-apple-darwin12 at r196444
Generated with...
/sw/src/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
Jack Howarth changed:
What|Removed |Added
Attachment #29521|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
--- Comment #8 from Jack Howarth 2013-02-22
02:03:14 UTC ---
Created attachment 29521
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29521
backport of gcc-4_7-branch fixes to gcc-4_6-branch
The attached patch backports the addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
--- Comment #7 from Jack Howarth 2013-02-22
02:01:10 UTC ---
Created attachment 29520
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29520
patch to fix gcc-4_7-branch bootstrap against texinfo 5.0
Current gcc-4_7-branch still fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938
Jack Howarth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #42 from Jack Howarth 2013-02-12
14:41:56 UTC ---
(In reply to comment #41)
FYI, most of the codegen issues with xplor-nih compiled with gfortran can be
suppressed with -fno-tree-vectorize at -O3 (hence my interest in a funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #50 from Jack Howarth 2013-02-11
17:54:44 UTC ---
(In reply to comment #47)
> Created attachment 29396 [details]
> revised patch to revert r184293 while fixing PR55693
>
> Bootstrap regtesting underway on ppc darwin9, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #49 from Jack Howarth 2013-02-08
18:17:50 UTC ---
The patch in comment 47 produces no regressions in gcc for...
make -k check RUNTESTFLAGS="tm.exp --target_board=unix'{-m32,-m64}'"
and none in libitm for...
make -k check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #48 from Jack Howarth 2013-02-08
14:40:20 UTC ---
(In reply to comment #47)
> Created attachment 29396 [details]
> revised patch to revert r184293 while fixing PR55693
>
> Bootstrap regtesting underway on ppc darwin9, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #47 from Jack Howarth 2013-02-08
14:39:11 UTC ---
Created attachment 29396
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29396
revised patch to revert r184293 while fixing PR55693
Bootstrap regtesting underway on ppc d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #44 from Jack Howarth 2013-02-07
19:33:24 UTC ---
Created attachment 29389
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29389
revised patch to fix darwin10 under Xcode 4.2
The attached patch removes the " && !defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #46 from Jack Howarth 2013-02-07
16:27:41 UTC ---
(In reply to comment #42)
Full regression test results on x86_64-apple-darwin12 are at...
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00745.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #44 from Jack Howarth 2013-02-07
13:49:36 UTC ---
Created attachment 29385
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29385
assembly file for failing gcc.target/i386/pr49866.c compilation at -m64
Compiled with...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
--- Comment #43 from Jack Howarth 2013-02-07
13:45:45 UTC ---
(In reply to comment #42)
On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps
fine, it does produce a new regression at -m64...
Executing on host: /
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #50 from Jack Howarth 2013-02-04
17:24:40 UTC ---
(In reply to comment #49)
> I agree with Jakub: it's better to return back to the qsort version of the
> patch, since it fixes ASan as well, but also provides better support for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #47 from Jack Howarth 2013-02-03
15:16:50 UTC ---
posted proposed patch and regression testresults at...
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00055.html
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00251.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #46 from Jack Howarth 2013-02-03
00:10:02 UTC ---
(In reply to comment #40)
Also with the patch in Comment 42, the failing test case converted into a
shared library loaded via dlopen works fine...
% cat libcov.C
struct c18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #45 from Jack Howarth 2013-02-02
22:53:59 UTC ---
(In reply to comment #40)
Also the impact of the proposed patch in Comment 42 could be limited even
further by using...
if (flag_asan && priority == 99)
as the test for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #44 from Jack Howarth 2013-02-02
20:41:15 UTC ---
(In reply to comment #40)
Doesn't the test case I showed in Comment 28 qualify as working across
translaional units? That test case still compiles and runs fine with
-fsanitize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #43 from Jack Howarth 2013-02-02
20:19:40 UTC ---
(In reply to comment #40)
Actually I think we should junk sorting entirely and use the alternative
approach of the patch in Comment 42. That approach should have no impact on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Jack Howarth changed:
What|Removed |Added
Attachment #29338|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #41 from Jack Howarth 2013-02-02
20:11:07 UTC ---
Created attachment 29338
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29338
alternative approach of only inserting asan static constructor in front
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #39 from Jack Howarth 2013-02-02
18:16:39 UTC ---
While testing whether the single qsort was sufficient, the origin of the
problem on darwin was clarified. In machopic_asm_out_constructor, after the
vec_safe_push, the construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #37 from Jack Howarth 2013-02-02
15:31:37 UTC ---
typedef struct GTY(()) ctor_record {
rtx symbol;
int priority; /* constructor priority */
int position; /* original position */
};
fails with...
..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #35 from Jack Howarth 2013-02-02
05:51:31 UTC ---
Created attachment 29334
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29334
working va_gc implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #33 from Jack Howarth 2013-02-01
21:45:42 UTC ---
Replacing the...
ctors->qsort (sort_by_ctor_priority);
with...
qsort(ctors, ctor_index+1, sizeof(ctor_record), sort_by_ctor_priority);
appears to solve the bootstrap i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #32 from Jack Howarth 2013-02-01
21:22:06 UTC ---
Created attachment 29332
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29332
first attempt at va_gc implementation
The attached patch is a first attempt at replacing th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #31 from Jack Howarth 2013-02-01
16:46:35 UTC ---
FYI, the proof of concept patch from Comment 27 produces no regressions in the
testsuite on x86_64-apple-darwin12...
http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00070.htm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #29 from Jack Howarth 2013-02-01
05:52:13 UTC ---
The proposed patch with dynamic allocation and qsort of the ctor records by
priority field reduces the number of unexpected failures for...
sudo make -k check-g++ RUNTESTFLAGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #28 from Jack Howarth 2013-02-01
03:00:37 UTC ---
qsort version of patch works with trivial shared lib test code of...
% cat libcov.C
struct c18 {
virtual void bar() { }
};
c18 ret;
% cat covmain.C
int main () {
}
%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Jack Howarth changed:
What|Removed |Added
Attachment #29324|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #26 from Jack Howarth 2013-02-01
02:30:10 UTC ---
Created attachment 29324
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29324
proposed patch for dynamic allocation and qsort of ctor records by priority
field.
propose
1 - 100 of 1110 matches
Mail list logo
