https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
--- Comment #10 from Jack Howarth ---
(In reply to Iain Sandoe from comment #8)
Why can't maybe_get_sysroot_from_sdkroot() be expanded so that it attempts to
execute 'xcrun --show-sdk-path' to obtain SDKROOT when unset? IMHO, this would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #10 from Jack Howarth ---
FYI, Xcode 11 is now released and being pushed, via App Store updates, to
Mojave users. So the gcc bootstrap is now officially broken on Mojave and
Catalina.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #7 from Jack Howarth ---
(In reply to Iain Sandoe from comment #6)
> We are not dependent on the Xcode supplied tools for some time now, since
> upstream dsymutil is functional. So, if that were to happen - we would
> simply (as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #5 from Jack Howarth ---
(In reply to Iain Sandoe from comment #3)
>
> 3. I don't see why GCC should be subject to the vendor's support policy. As
> far as I am concerned, with the right SDK / sysroot available, there's no
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #4 from Jack Howarth ---
A couple notes here.
1) As I mentioned in the duplicate PR 87257, Apple achieved the obsoleting of
the i386 support in Xcode 10 through the libSystem.tbd in the 10.14 SDK's
buried /usr/lib/libSystem.tbd
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The Xcode 10 release on x86_64-apple-darwin18 obsoletes i386 code generation as
its default behavior. This was achieved by having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243
--- Comment #2 from Jack Howarth ---
(In reply to Iain Sandoe from comment #1)
> I am strongly against making GCC's configure depend on xcrun. It is quite
> possible that GCC could be used, for example, with PureDarwin - or on
> systems without
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The Xcode 10 release on 10.14 deprecates the presence of the system headers in
/ such that the Command Line Tools package no longer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #25 from Jack Howarth ---
(In reply to Chris Johns from comment #24)
> I would welcome a patch attached to this ticket.
>
> My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to
> build. I have seen a build work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #16 from Jack Howarth ---
The component on this bug should probably be switched back off of 'target' to
'libstdc++' as the broken stamps implementation is likely just latent on other
targets because none of them have filesystems with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #15 from Jack Howarth ---
Maybe I'm just thick, but from the generated
x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely unclear
to me how the stamp mechanism and the current install-headers insures that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #13 from Jack Howarth ---
The following hack allows gcc 7.2.0 to complete the 3 stage bootstrap of the
c,c++,fortran,lto,objc,obj-c++ language set under High Sierra on an APFS
volume...
diff -uNr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #12 from Jack Howarth ---
Just to add in things that don't fix these failures, the following doesn't
help...
--- gcc-7.2.0/libstdc++-v3/include/Makefile.in.orig 2017-09-02
11:00:08.0 -0400
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #11 from Jack Howarth ---
For what it's worth, I managed to partially suppress the missing headers
bootstrap failure for libstdc++-v3 with the change...
++-v3/include/Makefile.in
--- libstdc++-v3/include/Makefile.in.orig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #10 from Jack Howarth ---
I managed to reproduce this issue on an 8 core non-HT system booted from an
APFS volume on an old SATA2 HDD so the issue doesn't seem to be dependent on
really fast IO...
Making all in include
mkdir -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #7 from Jack Howarth ---
(In reply to Romain from comment #6)
> Hi,
>
> > It might be an interesting exercise to encrypt the APFS volume and see if
> > that
> throws just enough additional filesystem overhead in to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #9 from Jack Howarth ---
Note that the main deviation from the previous back porting for gcc-6-branch is
that the ipa-icf-gimple.c source file must define INCLUDE_LIST since it is used
in that file for gcc-5-branch unlike
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #8 from Jack Howarth ---
Verified that proposed changes in PR81037_gcc5.patch with Xcode 8.2.1 on
darwin15.6.0 and Xcode 9 beta 5 on 10.13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #7 from Jack Howarth ---
Created attachment 42011
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42011=edit
proposed back port of changes from trunk for gcc-5-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #13 from Jack Howarth ---
(In reply to Francois-Xavier Coudert from comment #12)>
> Some potential confirmation of this: compiling with the 10.12 Xcode 8 on the
> 10.13 machine with APFS leads to the same error.
>
> Another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #11 from Jack Howarth ---
(In reply to Francois-Xavier Coudert from comment #10)
> (In reply to Jack Howarth from comment #9)
>
>
> The only thing I can think of is that maybe, just maybe, it's due to
> filesystem timestamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #9 from Jack Howarth ---
(In reply to Francois-Xavier Coudert from comment #8)
> Can reproduce with GNU Make 4.2.1, on the same system.
I assume all of these builds are done using a gcc7.rb file run under ruby,
correct? You might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #3 from Jack Howarth ---
(In reply to Jack Howarth from comment #1)
> Created attachment 41522 [details]
> reproducer for gcc 6.3.0 bootstrap failure with Xcode 9 beta
>
> bzip2 compressed archive with auto-profile.ii preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #2 from Jack Howarth ---
Created attachment 41523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41523=edit
reproducer for gcc 5.4.0 bootstrap failure with Xcode 9 beta
bzip2 compressed archive with auto-profile.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #1 from Jack Howarth ---
Created attachment 41522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41522=edit
reproducer for gcc 6.3.0 bootstrap failure with Xcode 9 beta
bzip2 compressed archive with auto-profile.ii
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
Current gcc-5-branch and gcc-6-branch fails to bootstrap against Xcode 9 beta
on 10.12 due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #54 from Jack Howarth ---
Shouldn't this be closed now as resolved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #52 from Jack Howarth ---
(In reply to Iain Sandoe from comment #51)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #50)
> > > --- Comment #49 from Iain Sandoe ---
> > [...]
> > > I can do darwin14 (I built 242408 last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #42 from Jack Howarth ---
(In reply to Jack Howarth from comment #41)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #39)
> > > --- Comment #36 from Jack Howarth ---
> > > Created attachment 40044 [details]
> > > -->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #41 from Jack Howarth ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #39)
> > --- Comment #36 from Jack Howarth ---
> > Created attachment 40044 [details]
> > -->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #37 from Jack Howarth ---
Created attachment 40045
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40045=edit
preprocessed source for sanitizer_mac.cc from stage3
preprocessed source for sanitizer_mac.cc from stage3 generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #36 from Jack Howarth ---
Created attachment 40044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044=edit
fixincludes trace.h generated in stage 1
fixincludes trace.h generated in stage 1 on darwin15 using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #35 from Jack Howarth ---
Created attachment 40043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40043=edit
stock /usr/include/os/trace.h from OS X 10.11.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #33 from Jack Howarth ---
Alternative fix posted at
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01366.html
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The commit of r242387 introduced new breakage in the darwin15 bootstrap.
g++ -std=gnu++98 -c -g -DIN_GCC-fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #32 from Jack Howarth ---
FYI, it looks like r242387 has introduced orthogonal breakage in the darwin
bootstrap...
[ -f stage_final ] || echo stage3 > stage_final
rm -f stage_current
make[4]: Nothing to be done for `all'.
make[3]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #30 from Jack Howarth ---
Created attachment 40035
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40035=edit
proposed fix for fixing darwin15 and earlier bootstraps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #27 from Jack Howarth ---
IMHO, the fixincludes approach looks much more fragile than simply using the
approach suggested in Comment 5 of...
Index: libsanitizer/sanitizer_common/sanitizer_mac.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #26 from Jack Howarth ---
Created attachment 40034
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40034=edit
trace.h differences between darwin15 and darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #9 from Jack Howarth ---
(In reply to Maxim Ostapenko from comment #6)
> Created attachment 40007 [details]
> Untested fix.
>
> Attaching untested fix.
> Dominique, could you try it?
The change fixes the bootstrap of current gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
--- Comment #2 from Jack Howarth ---
It appears that config/iconv.m4 needs to be reworked for its tests to succeed.
Removing INCICONV from CPPFLAGS on darwin causes the headers from /usr/include
to be accidentally used against the libs from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
--- Comment #1 from Jack Howarth ---
FYI, the only reason we never see the same breakage on fink as MacPorts is that
we don't happen to have a libunwinder package in our package set to expose us
to
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
While debugging the MacPorts build approach for FSF gcc and comparing it to our
own in the fink project, I ran across a surprising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78206
Jack Howarth changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78206
--- Comment #1 from Jack Howarth ---
Executing the failing configure test with the stage1 xgcc compiler appears as
follows...
# sandbox-exec -f
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/x86_64-apple-darwin15.6.0/libgcc/fink.sb
: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
I ran into a rather interesting bootstrap failure for all FSF gcc releases when
performed under an Apple sandbox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #43 from Jack Howarth ---
(In reply to Eric Gallager from comment #33)
> I'm not sure if this is due to the patches from this bug report, or if it's
> due to some other change made to GCC recently, but my fork of Emacs now
> fails to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
--- Comment #6 from Jack Howarth ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Jack Howarth from comment #4)
> > The Apple developers think this is gcc bug producing malformatted input to
> > the linker. From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
--- Comment #4 from Jack Howarth ---
The Apple developers think this is gcc bug producing malformatted input to the
linker. From macho_relocatable_file.cpp, we are triggering the linker check...
#ifndef NDEBUG
// scan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
--- Comment #3 from Jack Howarth ---
Opened radar://28914335 'linker crash when linking temacs from emacs 25.1 when
built with FSF gcc 6.2.0 or gcc trunk' with standalone test case attached as
reproducer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
--- Comment #2 from Jack Howarth ---
This issue is also observed on x86_64-apple-darwin14 using gcc 6.2.0 and the
linker from Xcode 7.2.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78087
--- Comment #2 from Jack Howarth ---
Note that these tests on linux used binutils-2.27.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78087
--- Comment #1 from Jack Howarth ---
Interestingly, the stock build of gcc 6.2.0 on x86_64 linux (with LTO plugin
linker plugin support) runs into a different set of failures when building
emacs 25.1 using '-O0 -flto'...
CCLD etags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #42 from Jack Howarth ---
Filed Bug lto/78087 for the linkage failure of temacs in the emacs 25.1 build
when '-O0 -flto' is used on x86_64 darwin and x86_64 linux (for a build without
the LTO linker plugin).
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The gcc 6.2.0 compiler fails to link temacs in a build of emacs 25.1 when the
"-O0 -flto" flag is passed on CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #41 from Jack Howarth ---
(In reply to Jack Howarth from comment #40)
> (In reply to Jack Howarth from comment #39)
> > (In reply to Eric Gallager from comment #38)
> >
> > Your issue of undefined symbols under FSF gcc is orthogonal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #40 from Jack Howarth ---
(In reply to Jack Howarth from comment #39)
> (In reply to Eric Gallager from comment #38)
>
> Your issue of undefined symbols under FSF gcc is orthogonal to the problem
> discussed in this PR. As I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #39 from Jack Howarth ---
(In reply to Eric Gallager from comment #38)
Your issue of undefined symbols under FSF gcc is orthogonal to the problem
discussed in this PR. As I mentioned before, the same issue is observed for a
build of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #37 from Jack Howarth ---
(In reply to Eric Gallager from comment #33)
> I'm not sure if this is due to the patches from this bug report, or if it's
> due to some other change made to GCC recently, but my fork of Emacs now
> fails to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077
--- Comment #1 from Jack Howarth ---
This Xcode 8 linker failure is suppressed when emacs 25.1 is built at -O0, but
occurs for -O1, -O2, -Os and -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #36 from Jack Howarth ---
(In reply to Jack Howarth from comment #35)
> (In reply to Eric Gallager from comment #33)
> > I'm not sure if this is due to the patches from this bug report, or if it's
> > due to some other change made to
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The gcc 6.2.0 release fails to link temacs in the build of emacs-25.1 on
x86_64-apple-darwin15 using the Xcode 8 linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #35 from Jack Howarth ---
(In reply to Eric Gallager from comment #33)
> I'm not sure if this is due to the patches from this bug report, or if it's
> due to some other change made to GCC recently, but my fork of Emacs now
> fails to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #32 from Jack Howarth ---
(In reply to Iain Sandoe from comment #30)
oblem with a small set of tests).
>
> I'm going to rebase and post the patches
Any ETA on the rebased patches being posted?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352
--- Comment #18 from Jack Howarth ---
(In reply to Andrew Pinski from comment #17)
> Is this still true?
This issue was fixed with...
r211067 | mrs | 2014-05-29 19:20:39 -0400 (Thu, 29 May 2014) | 4 lines
PR debug/61352
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #14 from Jack Howarth ---
(In reply to Jason Merrill from comment #13)
Is darwin the only target using TREE_TYPE rather than DECL_ARG_TYPE?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #12 from Jack Howarth ---
(In reply to Jakub Jelinek from comment #6)
> Shorter testcase:
> struct A {};
>
> void
> foo (struct A a, int b)
> {
> }
> compiles with sparc-solaris C, but doesn't with C++.
This test case doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #11 from Jack Howarth ---
In case it helps, with the proposed patch, the backtrace from fancy_abort in
the failing string-inst.cc compilation on darwin appears as...
(lldb) bt
* thread #1: tid = 0x54d252, 0x0001018798f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #10 from Jack Howarth ---
(In reply to Jason Merrill from comment #8)
> Created attachment 38269 [details]
> patch
>
> This fixes the reduced testcase for me on sparc, does it fix bootstrap on
> the various targets?
The proposed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #9 from Jack Howarth ---
Created attachment 38270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38270=edit
bzip2 compressed preprocessed source for libstdc++-v3/src/c++11/string-inst.cc
on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #2 from Jack Howarth ---
This regression is caused by the commit...
r234959 | jason | 2016-04-13 16:11:20 -0400 (Wed, 13 Apr 2016) | 7 lines
Pass
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
At r234969, the bootstrap of x86_64-apple-darwin15 fails with...
libtool: compile: /sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/./gcc/xgcc
-shared-libgcc -B/sw/src/fink.build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
--- Comment #7 from Jack Howarth ---
Also, note that upstream has in compiler-rt/cmake/config-ix.cmake...
if(SANITIZER_MIN_OSX_VERSION VERSION_LESS "10.7")
message(FATAL_ERROR "Too old OS X version: ${SANITIZER_MIN_OSX_VERSION}")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
--- Comment #6 from Jack Howarth ---
(In reply to Jakub Jelinek from comment #5)
> So can dyldVersionNumber be only used for #if SANITIZER_IOSSIM and otherwise
> use what it did before?
The IOSSIM code from llvm's sanitizer was never migrated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
NCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
The graphite test case...
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807
Jack Howarth changed:
What|Removed |Added
Target||x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #12 from Jack Howarth ---
I can confirm that the following change allows current gcc trunk to bootstrap
on x86_64-apple-darwin15.
Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #8 from Jack Howarth ---
(In reply to torvald from comment #7)
> Does this patch fix the issue on Darwin?
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01452.html
The proposed patch for libstdc++-v3/src/c++11/cow-stdexcept.cc is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #9 from Jack Howarth ---
I suspect the current problem is from...
// Declare all libitm symbols we rely on, but make them weak so that we do
// not depend on libitm.
in libstdc++-v3/src/c++11/cow-stdexcept.cc. There needs to be an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #10 from Jack Howarth ---
It is unclear if the changes in r232454, to avoid the explicit linkage on
libitm, can ever be made darwin-friendly. On darwin, every single executable
linked against libstdc++ would require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69179
--- Comment #1 from Jack Howarth ---
Note that weak_import was added by Geoffrey Keating in...
https://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html
and tweaked in...
https://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html
The last time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #28 from Jack Howarth ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #27)
> > --- Comment #25 from Jack Howarth ---
> [...]
> > Did you remember to install the patched build before attempting to run the
> > libjava test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #30 from Jack Howarth ---
(In reply to Iain Sandoe from comment #29)
> (In reply to Jack Howarth from comment #28)
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #27)
> > > > --- Comment #25 from Jack Howarth ---
>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69061
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Current gcc trunk for 6.0svn trails Clang 3.8svn in the both the tests passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69046
--- Comment #1 from Jack Howarth ---
Created attachment 37129
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37129=edit
log of 'make ctest' using -fopenmp -O3 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69046
--- Comment #3 from Jack Howarth ---
The regressions in the OpenMP3.1_Validation c test suite verifications in gcc
6.0svn's results compared to clang 3.8svn's are...
--- clang-3.8-openmp-validation.log 2015-12-24 13:04:43.0 -0500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69046
--- Comment #2 from Jack Howarth ---
Created attachment 37130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37130=edit
log of 'make ctest' using -fopenmp -O3 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #26 from Jack Howarth ---
Created attachment 37100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37100=edit
proposed patch to suppress PR66848 on darwin
The attached proposed patch suppresses PR66848 on darwin until either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #25 from Jack Howarth ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Dominique d'Humieres ---
> >> Yes. If you apply the ugly hack from comment 11, you will find that it
> >> fixes
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848
--- Comment #22 from Jack Howarth ---
(In reply to Dominique d'Humieres from comment #21)
>
> for both -m32 and -m64. Are they related?
Yes. If you apply the ugly hack from comment 11, you will find that it fixes
both the boehm-gc test suite
1 - 100 of 191 matches
Mail list logo
