[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[howarth.at.gcc at gmail dot com]

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
mitigate the overhead for the compiler as xrcun would only be called when
absolutely needed. The overall overhead in that case shouldn't be much worst
than Apple's compiler wrapper approach to calling their compiler through xcrun
itself.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[howarth.at.gcc at gmail dot com]

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.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #8 from Jack Howarth  ---
Jeremy's comment on this issue was...

"Although frankly, it is well past time that GCC add support for these macros
and attributes if they want to actually consider darwin a supported platform."

so I suspect upstream may expect FSF gcc to finally support these macros at
this late date.

[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[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

--- Comment #11 from Jack Howarth  ---
Just a reminder that clang solves finding the position of the SDK via xcrun and
SDKROOT.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

The compiler stub programs that users run execute the real clang compilers by
calling them via the xcrun program which sets the SDKROOT, among other
environmental variables, for the clang compiler to use.

ENVIRONMENT
   CPATH
  This   environment   variable   is  modified  by  xcrun  to  include
  /usr/local/include when an explicit SDK is not requested  via  envi-
  ronment variable nor command line argument and neither -nostdinc nor
  -nostdsysteminc are present.

   DEVELOPER_DIR
  Overrides the active developer directory. When DEVELOPER_DIR is set,
  its  value  will be used instead of the system-wide active developer
  directory.

   LIBRARY_PATH
  This  environment  variable  is  modified  by   xcrun   to   include
  /usr/local/lib when an explicit SDK is not requested via environment
  variable nor command line argument and -Z is not being passed to the
  linker.

   SDKROOT
  Specifies  the  default  SDK  to be used when looking up tools (some
  tools may have SDK specific versions).

  This environment variable is also set by xcrun to  be  the  absolute
  path  to  the  user  provided  SDK  (either via SDKROOT or the --sdk
  option), when it is used to invoke a normal  developer  tool  (build
  tools like xcodebuild or make are exempt from this behavior).

  For example, if xcrun is used to invoke clang via:
  xcrun --sdk macosx clang test.c

  then xcrun will provide the full path to the macosx SDK in the envi-
  ronment variable SDKROOT. That in turn will be used by  clang(1)  to
  automatically select that SDK when compiling the test.c file.

   TOOLCHAINS
  Specifies  the  default  toolchain  to be used when looking up tools
  (for tools which are toolchain specific).

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[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 Linux folks do) build a complete toolchain rather than just
> the compiler (i have a 'cctools' look-alike driver for the LLVM backend -
> and an actual cctools assembler with the known bugs fixed).
> 

While using the assembler from llvm should be straight forward enough, assuming
Apple didn't push its obsoleting of i386 changes upstream, the linker would be
a tricker issue since the llvm lld code hasn't been kept up on the Darwin side
for quite some time.

> To assist this, it would be helpful if fink, macports etc. could file radars
> noting that the open source releases are very out of date for these
> components (currently 8.2.1 compared with the released Xcode of 10.x)

I pinged Jeremy to see if he can nudge that along.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[howarth.at.gcc at gmail dot com]

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
> reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build
> code for i686-darwin10 *target*.

That makes the assumption that the cctools in some future macOS release won't
obsolete out the code for support i386 assembly and linkage. I wouldn't be
surprised if that actually happened should Apple start making
arm64-apple-darwin a thing.

[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build

[howarth.at.gcc at gmail dot com]

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 which only exposes the x86_64 symbols from the
root level /usr/lib/libSystem.dylib. So one could hack continued support for
i386 in for awhile more if gcc replaced its -lSystem linkage with an explicit
/usr/lib/libSystem.dylib linkage.

2) Since the default behavior for the command line tools from Xcode 10 are to
not install the SDK in the root directory, the gcc compiler needs to be
bootstrapped with--with-sysroot=$SDK_PATH to build under Xcode 10 on 10.14.
This issue doesn't exist on 10.13 which still installs the system headers in
the root directory.

[Bug target/87257] New: i386 multilib build should be disabled for x86_64-apple-darwin18

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87257

Bug ID: 87257
   Summary: i386 multilib build should be disabled for
x86_64-apple-darwin18
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  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 the 10.14 SDK's buried
/usr/lib/libSystem.tbd only expose the x86_64 symbols contained in the fat root
level /usr/lib/libSystem.dylib.   

$ clang -m32 hello.c
ld: warning: The i386 architecture is deprecated for macOS (remove from the
Xcode build setting: ARCHS)
ld: warning: ignoring file
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd,
missing required architecture i386 in file
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
Undefined symbols for architecture i386:
  "_printf", referenced from:
  _main in hello-04a500.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This can be fudged by installing the fall back header package for / so that the
/usr/lib/libSystem.dylib is used, but that package is slated for removal in a
later OS release and its use highly discouraged. So FSF gcc's configure should
be modified to default to disable-multilib for darwin18 and later.

[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK

[howarth.at.gcc at gmail dot com]

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 any Xcode install (using headers built from the OpenSource
> packages).
> 
> So, yes we have to find a solution to finding the headers,
> but no, (at least I don't agree) that trying into yet another tool we don't
> control is that solution.

The problem is finding a mechanism which doesn't use Apple's xcrun yet still
allows you to find the SDK since the location of Xcode.app can change with
renaming and hence the location of the SDK.

[Bug target/87243] New: FSF needs to use xcrun on darwin18 to find system headers in SDK

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243

Bug ID: 87243
   Summary: FSF needs to use xcrun on darwin18 to find system
headers in SDK
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  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 installs a /usr/include
directory. While Apple is providing a fall back header package to install the
SDK in /, this will be dropped in a future macOS release. 

   The Apple clang compilers aren't explicitly patched to address this issue.
Rather the compiler stubs in /usr/bin execute the compilers in the Xcode
application and the Command Line Tools via the xcrun program which sets the
SDKROOT environmental appropriately. Since installing compiler wrappers to do
this for FSF gcc would be problematic for the other targets, the better
approach would be to have the header search path enhanced to default to
-iwithsysroot `xcrun --sdk macosx --show-sdk-path` for FSF gcc.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 however most fail with a range of headers
> that can vary from build to build. I can see the massive `ln -s` happening
> and after the build fails and stops all the links are present.

Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local is
set to install-freestanding-headers instead of install-headers in
libstdc++-v3/include/Makefile.in? Perhaps you need...

.NOTPARALLEL: install-freestanding-headers

as well?

[Bug bootstrap/82091] [5 only] Build failure on macOS 10.13 with Xcode 9

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #3 from Jack Howarth  ---
Isn't this due to gcc-5-branch missing the proposed back port of...

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00476.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html

Iain Sandoe said he could only approve the objc bits and was waiting for the
appropriate maintainers to approve the rest of the patch before it could be
applied to gcc-5-branch.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[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 the fine time granularity of
APFS yet,

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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
install-headers has completed in its entirety.  

The way I read the current Makefile is that it is merely checking for the
existence of the include subdirectories having been installed and not that that
they have been completely populated. Looks like a broken implementation of
stamps to me.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in
gcc-7.2.0/libstdc++-v3/include/Makefile.in
--- gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in 2017-07-25
14:05:07.0 -0400
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 12:22:08.0
-0400
@@ -1764,6 +1764,8 @@
 @GLIBCXX_HOSTED_TRUE@install-data-local: install-headers
 @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers

+.NOTPARALLEL: install-headers
+
 # This is a subset of the full install-headers rule.  We only need ,
 # , , , , , , ,
 # , , , , ,

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 11:12:38.0
-0400
@@ -1887,16 +1887,37 @@
 # developer tries to create them via make in the include build
 # directory. (This is more of an example of how this kind of rule can
 # be made.)
-.PRECIOUS: $(std_headers) $(c_base_headers) $(tr1_headers) $(tr2_headers)
+.PRECIOUS: $(std_headers) $(bits_headers) $(c_base_headers) $(tr1_headers)
$(tr2_headers)
   $(decimal_headers) $(ext_headers) $(experimental_headers)
-  $(experimental_bits_headers)
+  $(experimental_bits_headers) $(bits_host_headers)
$(bits_sup_headers)
+  $(backward_headers) $(ext_compat_headers) $(ext_host_headers) 
+  $(experimental_filesystem_headers)
$(experimental_bits_filesystem_headers)
+  $(c_compatibility_headers) $(debug_headers) $(parallel_headers)
+  $(profile_headers) $(profile_impl_headers) $(host_headers)
$(thread_host_headers)
 $(std_headers): ; @:
+$(bits_headers): ; @:
+$(bits_host_headers): ; @:
+$(bits_sup_headers): ; @:
+$(backward_headers): ; @:
 $(c_base_headers): ; @:
 $(tr1_headers): ; @:
+$(tr2_headers): ; @:
 $(decimal_headers): ; @:
 $(ext_headers): ; @:
+$(ext_compat_headers): ; @:
+$(ext_host_headers): ; @:
 $(experimental_headers): ; @:
 $(experimental_bits_headers): ; @:
+$(experimental_filesystem_headers): ; @:
+$(experimental_bits_filesystem_headers): ; @:
+$(c_compatibility_headers): ; @:
+$(debug_headers): ; @:
+$(parallel_headers): ; @:
+$(profile_headers): ; @:
+$(profile_impl_headers): ; @:
+$(host_headers): ; @:
+$(thread_host_headers): ; @:
+

 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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   2017-08-29 22:22:17.0
-0400
+++ libstdc++-v3/include/Makefile.in2017-08-29 20:06:57.0 -0400
@@ -1761,7 +1761,7 @@
 # host_headers_extra are taken out of the build tree staging area;
 # the rest are taken from the original source tree.

-@GLIBCXX_HOSTED_TRUE@install-data-local: install-headers
+@GLIBCXX_HOSTED_TRUE@install-data-local: install-freestanding-headers
 @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers

 # This is a subset of the full install-headers rule.  We only need ,

However this change just moves the missing header error from stage1 to stage2.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin17.0.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin17.0.0/sys-include-x c++-header -nostdinc++
-g -O2 
-I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/libsupc++
-I/sw/include -O2 -g -std=gnu++0x
/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h
\
-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch
/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin17.0.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin17.0.0/sys-include-x c++-header -nostdinc++
-g -O2 
-I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/libsupc++
-I/sw/include -O2 -g
/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch
/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h:35:10:
fatal error: cctype: No such file or directory
 #include 
  ^~~~
compilation terminated.
make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1
make[5]: *** Waiting for unfinished jobs
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[1]: *** [stage1-bubble] Error 2

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 problem go
> latent.
> 
> I'm also trying to compile gcc-7.2.0 on macOS 10.13, and I'm using encrypted
> APFS, but it does not make this bug disappear.
> 
> Regards,
> Romain

FX and Romain,
 How many cores does each of your build systems have? Jeremy Sequoia says
he hasn't seen this on any of his build systems with APFS for MacPorts gcc6 or
later bootstraps but he is using 4 core systems in each case. I have seen
instances where particular race conditions don't show up on 8 core systems but
plague dual core systems.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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 gcc-6-branch.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 difference between HFS+ and APFS is file ordering: “Calling
> readdir(2) on a directory in APFS returns filenames in hash order, whereas
> HFS+ returns filenames in lexicographical order.”

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 problem go
latent.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 granularity? My 10.13 system is running on APFS
> filesystem, which has 1 ns granularity (smaller than 1 s for HFS+).

That sounds much more likely as the trigger for the problem. I only have hard
drives to test 10.13 on so I am stuck with HFS (and wouldn't press the envelope
with APFS without using it on an SSD).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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 try a manual build outside of ruby (but duplicating there
exact build approach). 

There is a history of certain race condition bugs only being exposed when make
is run under a particular program...

http://savannah.gnu.org/bugs/index.php?46261

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #3 from Jack Howarth  ---
I don't see this issue with the gcc7-7.1.0-1 fink package build on High Sierra.
This is from a clean install of fink master on 10.13 using the proposed changes
from...

https://github.com/fink/fink/pull/143

to bootstrap fink git master on 10.13 and patching all the fink package
dependencies that trip over the increased format string strictness in 10.13...

http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00056.html

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[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 source to
> reproduce bootstrap failure under Xcode 9 beta on OS X 10.12 using the
> supplied compile shell script.

The offending preprocessed source in this case is actually darwin-driver.ii.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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 preprocessed source to reproduce
bootstrap failure under Xcode 9 beta on OS X 10.12 using the supplied compile
shell script.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

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 preprocessed source to reproduce
bootstrap failure under Xcode 9 beta on OS X 10.12 using the supplied compile
shell script.

[Bug bootstrap/81037] New: Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037

Bug ID: 81037
   Summary: Xcode 9 requires back ports on gcc-5-branch and
gcc-6-branch for bootstrapping under Xcode 9
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  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 to the absence of back ports from gcc-7-branch (which does
bootstrap). The first issue is the bootstrap failure of...

g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common -DHAVE_CONFIG_H -o darwin-driver.o darwin-driver.ii

../../gcc-6.3.0/gcc/config/darwin-driver.c:302:13: error: cannot initialize a
variable of type 'char *' with an rvalue of type
  'const char *'
  char *first_period = strchr(vers_string, '.');
^  
Back porting the fix from 

https://github.com/gcc-mirror/gcc/commit/5972cd58bde3bc8bacfe994e5b127c411241f255.patch

The second failure specific to gcc-5-branch is...

g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o
auto-profile.o auto-profile.ii

In file included from ../../gcc-5.4.0/gcc/auto-profile.c:26:
In file included from
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/map:446:
/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/functional:1398:2:
error: no member
  named 'fancy_abort' in namespace 'std::__1'; did you mean simply
'fancy_abort'?
 std::__1::fancy_abort
("/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/func...
 ^~

I suspect this can be fixed by back porting both...

https://github.com/gcc-mirror/gcc/commit/49622efa89937fa310add53b1efb50273ec0d857

and

https://github.com/gcc-mirror/gcc/commit/ec8c949f8f296d1270fc41404175cd7249df4cd4

Unfortunately the second patch doesn't apply cleaning on gcc-5-branch and may
require additional back ports to do so.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767

--- Comment #54 from Jack Howarth  ---
Shouldn't this be closed now as resolved?

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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 night with the patches-in-progress 
> > > +
> > > __BLOCKS__) but that's a little bit more than the minimum
> > > (darwin_availabilityinternal + __BLOCKS__)
> > >
> > > choice 1.  Rainer splits out the minimum (darwin_availabilityinternal) 
> > > from his
> > > original patch and we put that together with the __BLOCKS__ one.
> > >
> > > choice 2. Rainer posts his current patch (which is at least correcting 
> > > some of
> > > the problems, even if not complete) and we apply that together with the
> > > __BLOCKS__ one.
> > 
> > Right now, I've got nothing beyond
> > 
> > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01348.html
> > 
> > Once we hit the Darwin 15 roadblock with _os_trace_with_buffer being
> > unavailable, I didn't try further and also didn't start looking into the
> > Darwin 14 issues.
> > 
> > I think choice 2 is right: the fixincludes fixes all fix real issues in
> > system headers, libsanitizer nonewithstanding.  We can develop further
> > fixes for Darwin 14 later, even if they are not needed to get
> > libsanitizer to build.
> > 
> > If we go this route, we know that it works on Darwin 16 (tested by
> > myself; it does even with the __BLOCKS__ one) and 15 (Jack confirmed
> > this).  If you can check on 14, I think we're set for now.
> 
> I guess both parts have been approved independently...

Confirmed that choice 2 (both parts) completes a 3-stage bootstrap with
comparison on darwin14.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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/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/ml/gcc-patches/2016-11/msg01045.html
> > 
> > So the fix has worked as expected/designed.  Good to have the confirmation.
> > 
> > Rainer
> 
> I see the problem now. Your proposed fix from
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply
> insufficient in the absence of the change proposed in Comment 33...
> 
> 2016-11-14  Jack Howarth  
> 
> libsanitizer/
> 
>   PR sanitizer/78267
>   * sanitizer_common/sanitizer_mac.cc: Include  only if
>   compiler supports blocks extension.
> 
> 
> Index: libsanitizer/sanitizer_common/sanitizer_mac.cc
> ===
> --- libsanitizer/sanitizer_common/sanitizer_mac.cc(revision 242387)
> +++ libsanitizer/sanitizer_common/sanitizer_mac.cc(working copy)
> @@ -34,7 +34,7 @@
>  extern char **environ;
>  #endif
>  
> -#if defined(__has_include) && __has_include()
> +#if defined(__has_include) && __has_include() &&
> defined(__BLOCKS__)
>  #define SANITIZER_OS_TRACE 1
>  #include 
>  #else
> 
> Otherwise the definition of SANITIZER_OS_TRACE results in
> libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace().

And of course that change negates the need for a fix-includes at all.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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/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/ml/gcc-patches/2016-11/msg01045.html
> 
> So the fix has worked as expected/designed.  Good to have the confirmation.
> 
>   Rainer

I see the problem now. Your proposed fix from
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply
insufficient in the absence of the change proposed in Comment 33...

2016-11-14  Jack Howarth  

libsanitizer/

PR sanitizer/78267
* sanitizer_common/sanitizer_mac.cc: Include  only if
compiler supports blocks extension.


Index: libsanitizer/sanitizer_common/sanitizer_mac.cc
===
--- libsanitizer/sanitizer_common/sanitizer_mac.cc  (revision 242387)
+++ libsanitizer/sanitizer_common/sanitizer_mac.cc  (working copy)
@@ -34,7 +34,7 @@
 extern char **environ;
 #endif

-#if defined(__has_include) && __has_include()
+#if defined(__has_include) && __has_include() &&
defined(__BLOCKS__)
 #define SANITIZER_OS_TRACE 1
 #include 
 #else

Otherwise the definition of SANITIZER_OS_TRACE results in
libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace().

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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 with...

[Jacks-Mac-Pro:x86_64-apple-darwin15.6.0/libsanitizer/sanitizer_common] root#
/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../gcc-7-20161114/libsanitizer/sanitizer_common -I.. -I
../../../../gcc-7-20161114/libsanitizer/include -isystem
../../../../gcc-7-20161114/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin15.6.0
-I../../../../gcc-7-20161114/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -g -O2 -MT sanitizer_mac.lo -MD -MP -MF .deps/sanitizer_mac.Tpo -c
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc
-fno-common -DPIC -o .libs/sanitizer_mac.o --save-temps
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Address Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Address Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Address Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Undefined Behavior Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Undefined Behavior Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Undefined Behavior Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Thread Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Thread Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Thread Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Sanitizer tool reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Sanitizer tool reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Sanitizer tool reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Consult syslog for more information.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Consult syslog for more information.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Consult syslog for more information.");

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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/ml/gcc-patches/2016-11/msg01045.html

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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

[Bug bootstrap/78347] New: r242387 breaks darwin bootstrap

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78347

Bug ID: 78347
   Summary: r242387 breaks darwin bootstrap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  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-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I../../gcc-7-20161114/gcc -I../../gcc-7-20161114/gcc/build
-I../../gcc-7-20161114/gcc/../include 
-I../../gcc-7-20161114/gcc/../libcpp/include -I/sw/include \
-o build/gengtype-parse.o
../../gcc-7-20161114/gcc/gengtype-parse.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
g++ -std=gnu++98 -c   -g  -DIN_GCC-fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I../../gcc-7-20161114/gcc -I../../gcc-7-20161114/gcc/build
-I../../gcc-7-20161114/gcc/../include 
-I../../gcc-7-20161114/gcc/../libcpp/include -I/sw/include \
-o build/gengtype-state.o
../../gcc-7-20161114/gcc/gengtype-state.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
In file included from ../../gcc-7-20161114/gcc/gengtype-state.c:36:
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
   lbasename (__FILE__),__LINE__, ##__VA_ARGS__);} while (0)
  ^
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
../../gcc-7-20161114/gcc/gengtype.h:497:40: warning: token pasting of ',' and
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
19 warnings generated.
g++ -std=gnu++98   -g  -DIN_GCC-fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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]: Nothing to be done for `all'.
make[4]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
true  DO=all multi-do # /Applications/Xcode.app/Contents/Developer/usr/bin/make
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all'.
make[3]: *** No rule to make target `../../gcc-7-20161114/gcc/c/c-parser.h',
needed by `s-gtype'.  Stop.
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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
===
--- libsanitizer/sanitizer_common/sanitizer_mac.cc  (revision 242386)
+++ libsanitizer/sanitizer_common/sanitizer_mac.cc  (working copy)
@@ -34,7 +34,7 @@
 extern char **environ;
 #endif

-#if defined(__has_include) && __has_include()
+#if defined(__has_include) && __has_include() &&
defined(__clang__)
 #define SANITIZER_OS_TRACE 1
 #include 
 #else

Even if you fix the regex selection in the proposed fixincludes for darwin15
and all prior OS X releases, the fix will still be fragile to future breakage
should the os/trace.h context change again.

The approach suggested in Comment 15 is robust and immune to that issue.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[howarth.at.gcc at gmail dot com]

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 trunk here on
x86_64-apple-darwiin15 against Xcode 8.2 beta.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

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 /opt/local/lib...

configure:10761: /usr/bin/clang++ -arch x86_64 -std=gnu++98 -o conftest -g
-Wl,-no_pie  conftest.cpp  -L/opt/local/lib -liconv >&5

fails because -I/opt/local/include was dropped. This should be available to
configure already from...

--with-libiconv-prefix[=DIR]

without resorting to CPPFLAGS to pass it around to the Makefile.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

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 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14925

We do however end up with the same contamination of CPPFLAGS late in the build
(in our case with contamination by -I/sw/include). 

Also, in the case of 

  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib

this process results in DIR being placed on CPPFLAGS instead of being keep on
the INCLUDES lines of individual Makefile.in instead. My initial attempts to
detangle this have been along the lines of...

--- gcc/Makefile.in.orig2016-11-08 03:29:02.0 -0500
+++ gcc/Makefile.in 2016-11-08 03:29:56.0 -0500
@@ -1063,7 +1063,7 @@
 # currently being compiled, in both source trees, to be examined as well.
 # libintl.h will be found in ../intl if we are using the included libintl.
 INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-  -I$(srcdir)/../include @INCINTL@ \
+  -I$(srcdir)/../include @INCINTL@ ${INCICONV} \
   $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
   $(ISLINC)

--- libstdc++-v3/src/Makefile.in.orig   2016-11-08 02:14:37.0 -0500
+++ libstdc++-v3/src/Makefile.in2016-11-08 02:15:15.0 -0500
@@ -126,7 +126,7 @@
 @VTV_CYGMIN_TRUE@am_libvtv_la_OBJECTS = vtv_stubs.lo
 libvtv_la_OBJECTS = $(am_libvtv_la_OBJECTS)
 @VTV_CYGMIN_TRUE@am_libvtv_la_rpath = -rpath $(toolexeclibdir)
-DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
+DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir) -I${INCICONV}
 depcomp =
 am__depfiles_maybe =
 CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
--- libstdc++-v3/configure.orig 2016-11-08 02:00:42.0 -0500
+++ libstdc++-v3/configure  2016-11-08 02:10:25.0 -0500
@@ -28529,7 +28529,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -40804,7 +40803,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -46928,7 +46926,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -59755,7 +59752,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
--- libstdc++-v3/configure.orig 2016-11-08 02:33:18.0 -0500
+++ libstdc++-v3/configure  2016-11-08 02:34:41.0 -0500
@@ -28596,7 +28596,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -40870,7 +40870,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -46993,7 +46993,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -59819,7 +59819,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
--- gcc/configure.orig  2016-11-08 02:53:20.0 -0500
+++ gcc/configure   2016-11-08 02:56:53.0 -0500
@@ -10681,7 +10681,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 

[Bug bootstrap/78251] New: config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

Bug ID: 78251
   Summary: config/gettext.m4 and config/iconv.m4 contaminate
CPPFLAGS
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  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 result. The MacPorts project
builds fail when their libunwinder-headers package is installed in their
${prefix} which is /opt/local. I expected to be able to solve this by building,
like fink, with CPPFLAGS and LDFLAGS unset (i.e. no -I/opt/local/include on
CPPFLAGS and -L/opt/local/lib on LDFLAGS) but instead to rely on the individual
--with-*= configure options to sort the paths out. 

Weirdly the build starts out fine and the initially generated Makefiles always
retain...

CPPFLAGS=

but once the build hits any configure which used config/gettext.m4 or
config/iconv.m4, CPPFLAGS gets contaminated with INCICONV or LIBICONV_INCLUDE.

Why can't config/gettext.m4 and config/iconv.m4 be restructured to perform its
tests without contaminating the previous contents of CPPFLAGS in the process?

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78206

Jack Howarth  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Jack Howarth  ---
(In reply to Andrew Pinski from comment #2)
> GCC by default looks to /usr/local unless you use with-local-prefix option.

Actually on darwin this isn't that simple. If you use --with-local-prefix= set
to anything other than /usr/lcoal, a potential header/library mismatch
situation is made possible because the compiler no longer searches
/usr/local/include for headers bu the linker command does still search
/usr/local/lib. Fortunately, this glitch is trivial to solve without resorting
to the --with-local-prefix hack. The simple change...

--- gcc/incpath.c.bak   2015-01-05 07:33:28.0 -0500
+++ gcc/incpath.c   2016-11-06 07:25:20.0 -0500
@@ -256,7 +256,7 @@
   if (stat (cur->name, ))
{
  /* Dirs that don't exist are silently ignored, unless verbose.  */
- if (errno != ENOENT)
+ if ((errno != ENOENT) && (errno != EPERM))
cpp_errno (pfile, CPP_DL_ERROR, cur->name);
  else
{

eliminates the compiler bootstrap failures and later compiler operation
failures when run under an Apple sandbox with file access to /usr/local denied.

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

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
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc5/x86_64q-darwin15.6.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include -c -g -O2 conftest.c -v
--save-temps
Reading specs from /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/specs
COLLECT_GCC=/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/xgcc
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc-5.4.0/configure --prefix=/sw --prefix=/sw/lib/gcc5
--mandir=/sw/share/man --infodir=/sw/lib/gcc5/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--with-local-prefix=/usr/local --program-suffix=-fsf-5
Thread model: posix
gcc version 5.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.11.6' '-B'
'/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/' '-B'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/bin/' '-B'
'/sw/lib/gcc5/x86_64q-darwin15.6.0/lib/' '-isystem'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include' '-isystem'
'/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include' '-c' '-g' '-O2' '-v'
'-save-temps' '-mtune=core2'
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/cc1 -E -quiet -v -iprefix
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/
-isystem /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include -isystem
/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include-fixed -D__DYNAMIC__
-isystem /sw/lib/gcc5/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include conftest.c -fPIC
-feliminate-unused-debug-symbols -mmacosx-version-min=10.11.6 -mtune=core2 -g
-fworking-directory -O2 -fpch-preprocess -o conftest.i
ignoring nonexistent directory "/sw/lib/gcc5/x86_64-apple-darwin15.6.0/include"
ignoring nonexistent directory
"/sw/lib/gcc5/x86_64-apple-darwin15.6.0/sys-include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include-fixed"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/../../../../x86_64-apple-darwin15.6.0/include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include"
cc1: error: /usr/local/include: Operation not permitted
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/include-fixed"
ignoring nonexistent directory
"/sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/gcc/../lib/gcc/../../lib/gcc/x86_64-apple-darwin15.6.0/5.4.0/../../../../x86_64-apple-darwin15.6.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include
 /sw/src/fink.build/gcc5-5.4.0-3/darwin_objdir/./gcc/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.

[Bug driver/78206] New: bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78206

Bug ID: 78206
   Summary: bootstrap failure under Apple sandbox that blacklists
reads in /usr/local
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: 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 configured to blacklist reads in /usr/local.
The libgcc configure run using the stage1 xgcc compiler fails with the error...

configure:3462: /sw/src/fink.build/gcc6-6.2.0-2/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc6-6.2.0-2/darwin_objdir/./gcc/
-B/sw/lib/gcc6/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc6/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.6.0/sys-include-o conftest -g -O2  
conftest.c  >&5
cc1: error: /usr/local/include: Operation not permitted

This bootstrap failure is suppressed if the configure option
--with-local-prefix=/sw or --with-local-prefix=/ is passed under the sandbox
build.

I assume cc1 is performing an stat() call on the /usr/include directory which
fails  in an unrecoverable manner due to the sandbox.

Note the Apple sandbox in this case was run with 'sandbox-exec -f fink.sb'
where the fink.sb file contained...

(version 1)

(allow default)

(deny file*
   (subpath "/usr/local")
)

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 build with LTO due to a bunch of undefined local symbols:
> 

This issue appears to be PR57438 because passing
-D__builtin_unreachable=__builtin_trap to the build on OS X 10.11 allows emac
25.1 to build against the Xcode 8.1 GM linker using stock gcc 6.2.0 compiler
with...

  $ ../configure --enable-link-time-optimization --without-ns
CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6
CPPFLAGS="-D__builtin_unreachable=__builtin_trap -I/sw/include"
LDFLAGS="-L/sw/lib"

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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 macho_relocatable_file.cpp, we are triggering the linker
> > check...
> > 
> > #ifndef NDEBUG
> > // scan for FDEs claming the same function
> > for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
> > assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
> > }
> > #endif
> 
> If it's a 0-length FDE caused by a 0-length function, then this is a repeat
> of 57438.  If so please mark it accordingly  (I expect to post a fix for
> 57438 soon, and I can send you a preview if that helps).
> 
> If this is something different, then please can we have a reduced test-case.
> Thanks

A reduced test case is unlikely but I can confirm that this appears to be due
to PR57438 since passing -D__builtin_unreachable=__builtin_trap by using...

../configure --enable-link-time-optimization --without-ns CC=/sw/bin/gcc-fsf-6
CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-D__builtin_unreachable=__builtin_trap
-I/sw/include" LDFLAGS="-L/sw/lib"

produces a successful build at -O2 with LTO under stock gcc 6.2.0 and Xcode 8.1
GM's linker.

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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 for FDEs claming the same function
for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
assert( cfiStartsArray[i] != cfiStartsArray[i-1] );
}
#endif

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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.

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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.

[Bug lto/78087] gcc 6.2.0 fails to link temacs from emacs-25.1 with -O0 -flto

[howarth.at.gcc at gmail dot com]

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.

[Bug lto/78087] gcc 6.2.0 fails to link temacs from emacs-25.1 with -O0 -flto

[howarth.at.gcc at gmail dot com]

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
/tmp/ccS55vep.ltrans4.ltrans.o: In function `skip_spaces.lto_priv.60':
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:6677: undefined
reference to `c_isspace'
/tmp/ccS55vep.ltrans4.ltrans.o: In function `skip_non_spaces.lto_priv.71':
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:6686: undefined
reference to `c_isspace'
...
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:1209: undefined
reference to `rpl_optind'
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:1263: undefined
reference to `set_binary_mode'
collect2: error: ld returned 1 exit status

or using '-O2 -flto'...

  CCLD etags
/tmp/ccaauRE2.ltrans1.ltrans.o: In function `strcaseeq':
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:162: undefined
reference to `c_strcasecmp'
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:162: undefined
reference to `c_strcasecmp'
/tmp/ccaauRE2.ltrans1.ltrans.o: In function `main':
...
/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:174: undefined
reference to `c_strncasecmp'
/tmp/ccaauRE2.ltrans4.ltrans.o:/home/howarth/emacs-25.1/build/lib-src/../../lib-src/etags.c:174:
more undefined references to `c_strncasecmp' follow
collect2: error: ld returned 1 exit status

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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).

[Bug lto/78087] New: gcc 6.2.0 fails to link temacs from emacs-25.1 with -O0 -flto

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78087

Bug ID: 78087
   Summary: gcc 6.2.0 fails to link temacs from emacs-25.1 with
-O0 -flto
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  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 and "-flto" on LDFLAGS. This issue occurs
on x86_64-apple-darwin15 where the failure appears as...

  CCLD temacs
/var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error:
assembler local symbol 'L1' not defined
...
/var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error:
assembler local symbol 'L174' not defined

and on x86_64 linux using a build gcc 6.2.0 with configure edited to set
build_lto_plugin=no on ELF to use the same code LTO code generation path on
linux as darwin...

  CCLD temacs
/tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x135a0): undefined reference to `.L1'
...
/tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x13bc8): more undefined references to
`.L174' follow
collect2: fatal error: ld returned 1 exit status

On x86_64 linux, the issue is suppressed when the -O1 optimization level or
higher is used.
On x86_64 darwin, the linker failure in PR78077 occurs when the -O1
optimization level or higher is used.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 to the problem
> > discussed in this PR. As I mentioned before, the same issue is observed for
> > a build of stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc
> > 6.2.0 compiler. You should open a separate PR for that bug.
> 
> Your bug might be reproducible on linux using a gcc build that doesn't have
> build_lto_plugin set by configure so the same LTO code path is used as on
> darwin.

FYI, I was able to reproduce the same bug on x86_64 linux when building emacs
25.1 with -flto using a build of gcc 6.2.0 with configure manually edited to
set build_lto_plugin=no on linux.

  CCLD temacs
/tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x135a0): undefined reference to `.L1'
...
/tmp/cc7ZBmmQ.ltrans0.ltrans.o:(.rodata+0x13bc8): more undefined references to
`.L174' follow
collect2: fatal error: ld returned 1 exit status

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 mentioned before, the same issue is observed for
> a build of stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc
> 6.2.0 compiler. You should open a separate PR for that bug.

Your bug might be reproducible on linux using a gcc build that doesn't have
build_lto_plugin set by configure so the same LTO code path is used as on
darwin.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 stock emacs 25.1 with '-O0 -flto' using a stock (unpatched) gcc 6.2.0
compiler. You should open a separate PR for that bug.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 build with LTO due to a bunch of undefined local symbols:

This issue exists in stock gcc 6.2.0 on x86_64-apple-darwin15. I can reproduce
the issue building emacs 25.1 configured with...

../configure --without-ns --prefix=/Users/howarth/emacs-dist
CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6 CPPFLAGS="-I/sw/include"
LDFLAGS="-flto -fno-pie -L/sw/lib" CFLAGS="-O0 -g -fno-pie -flto"

which produces a build that fails at...

  CCLD temacs
/var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error:
assembler local symbol 'L1' not defined
...
/var/folders/vh/xthx1f251nqfj804049zl1wmgn/T//cc5Viitn.s:288358:1: error:
assembler local symbol 'L174' not defined

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

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.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 GCC recently, but my fork of Emacs now
> > fails to build with LTO due to a bunch of undefined local symbols:
> 
> Did you actually add the patches for this bug report to your local gcc
> build? The patches haven't been posted to gcc-patches yet or committed into
> trunk.

I can't reproduce that particular failure in a build of emacs 25.1 against gcc
6.2.0 (with or without patchiest cf 240230 applied) because I run into a linker
bug when linking temacs using the Xcode 8 linker).

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077

[Bug target/78077] New: gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78077

Bug ID: 78077
   Summary: gcc 6.2.0 fails to link temacs from emacs-25.1 using
the Xcode 8 linker
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  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. Configuring a build as...

../configure --without-ns CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6
CPPFLAGS="-I/sw/include" LDFLAGS="-L/sw/lib"

results in a build that fails at...

  CCLD temacs
0  0x1097875cc  __assert_rtn + 144
1  0x10979a9df 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 3195
2  0x109792536  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, ld::File::Ordinal,
mach_o::relocatable::ParserOptions const&) + 342
3  0x1097d3bac  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 824
4  0x1097d640b  ld::tool::InputFiles::parseWorkerThread() + 495
5  0x7fff99bde99d  _pthread_body + 131
6  0x7fff99bde91a  _pthread_body + 0
A linker snapshot was created at:
/tmp/temacs-2016-09-22-161008.ld-snapshot
ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function
parse, file
/Library/Caches/com.apple.xbs/Sources/ld64/ld64-274.1/src/ld/parsers/macho_relocatable_file.cpp,
line 1893.
collect2: error: ld returned 1 exit status

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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 build with LTO due to a bunch of undefined local symbols:

Did you actually add the patches for this bug report to your local gcc build?
The patches haven't been posted to gcc-patches yet or committed into trunk.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[howarth.at.gcc at gmail dot com]

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?

[Bug target/60563] FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #15 from Jack Howarth  ---
(In reply to Dominique d'Humieres from comment #14)
> > Filed radr://19802258 and uploaded a standalone test case for the darwin
> > linker developer to debug with.
> 
> Jack,
> 
> Did you get any feedback from Apple?

No feedback and the issue still exists with the Xcode 8.1 beta linker and gcc
trunk.

[Bug target/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[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
* collect2.c (maybe_run_lto_and_relink): Be sure to always run
post ld passes when lto is used.

and the associated back port to gcc-4_9-branch.

[Bug libgomp/65385] [libgomp] omp task untied test case fails

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #5 from Jack Howarth  ---
FYI, this test is now supported in llvm's openmp support in clang trunk as
of...


r266853 | abataev | 2016-04-20 00:01:36 -0400 (Wed, 20 Apr 2016) | 5 lines

[OPENMP] Codegen for untied tasks.

If the untied clause is present on a task construct, any thread in the
team can resume the task region after a suspension. Patch adds proper
codegen for untied tasks.

It now produces the expected results of...

#Tested Directive   t   ct  ot  oct
omp_task_untied 100 100 100 100

on x86_64-apple-darwin15 for -m32 and -m64.

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[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?

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[howarth.at.gcc at gmail dot com]

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 trigger an ICE in the compiler on x86_64 darwin with or
without the proposed patch for the sparc bootstrap failure.

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[howarth.at.gcc at gmail dot com]

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
cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546,
function="emit_move_insn") + 19 at diagnostic.c:1329, queue =
'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0001018798f3
cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546,
function="emit_move_insn") + 19 at diagnostic.c:1329
frame #1: 0x000100da030b cc1plus`emit_move_insn(x=0x00010534cea0,
y=0x00010534ce58) + 123 at expr.c:3545
frame #2: 0x000100dca4b0 cc1plus`emit_single_push_insn_1(mode=QImode,
x=0x00010534ce58, type=0x0001026b1dc8) + 656 at expr.c:4033
frame #3: 0x000100dab5e9 cc1plus`emit_single_push_insn(mode=QImode,
x=0x00010534ce58, type=0x0001026b1dc8) + 57 at expr.c:4045
frame #4: 0x000100dab1a7 cc1plus`emit_push_insn(x=0x00010534ce58,
mode=QImode, type=0x0001026b1dc8, size=0x, align=64,
partial=0, reg=0x, extra=0, args_addr=0x,
args_so_far=0x000144808480, reg_parm_stack_space=0,
alignment_pad=0x000144808480, sibcall_p=true) + 3815 at expr.c:4384
frame #5: 0x000100bc315c cc1plus`store_one_arg(arg=0x7fff5fbfd750,
argblock=0x, flags=0, variable_size=0, reg_parm_stack_space=0)
+ 3036 at calls.c:4883
frame #6: 0x000100bbbf16 cc1plus`expand_call(exp=0x000105297b40,
target=0x, ignore=1) + 10550 at calls.c:3191
frame #7: 0x000100dbcb8f
cc1plus`expand_expr_real_1(exp=0x000105297b40, target=0x,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x,
inner_reference_p=false) + 25647 at expr.c:10601
frame #8: 0x000100db4297
cc1plus`expand_expr_real(exp=0x000105297b40, target=0x000144808480,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x,
inner_reference_p=false) + 215 at expr.c:7961
frame #9: 0x000100bf44d1 cc1plus`expand_expr(exp=0x000105297b40,
target=0x000144808480, mode=VOIDmode, modifier=EXPAND_NORMAL) + 49 at
expr.h:256
frame #10: 0x000100bf3a2e
cc1plus`expand_call_stmt(stmt=0x000104d79c78) + 2158 at cfgexpand.c:2661
frame #11: 0x000100bf051e
cc1plus`expand_gimple_stmt_1(stmt=0x000104d79c78) + 430 at cfgexpand.c:3549
frame #12: 0x000100bee523
cc1plus`expand_gimple_stmt(stmt=0x000104d79c78) + 131 at cfgexpand.c:3715
frame #13: 0x000100bef993
cc1plus`expand_gimple_tailcall(bb=0x000104fb7a28, stmt=0x000104d79c78,
can_fallthru=0x7fff5fbff07f) + 35 at cfgexpand.c:3762
frame #14: 0x000100be7ff8
cc1plus`expand_gimple_basic_block(bb=0x000104fb7a28,
disable_tail_calls=false) + 4072 at cfgexpand.c:5698
frame #15: 0x000100be4e9a cc1plus`(anonymous
namespace)::pass_expand::execute(this=0x000143914260,
fun=0x000104d79738) + 4074 at cfgexpand.c:6345
frame #16: 0x0001011eb28a
cc1plus`execute_one_pass(pass=0x000143914260) + 762 at passes.c:2336
frame #17: 0x0001011ebdf7
cc1plus`execute_pass_list_1(pass=0x000143914260) + 103 at passes.c:2420
frame #18: 0x0001011dcf6d
cc1plus`execute_pass_list(fn=0x000104d79738, pass=0x000143910de0) + 77
at passes.c:2431
frame #19: 0x000100c3c50c
cc1plus`cgraph_node::expand(this=0x000104989b80) + 540 at cgraphunit.c:1982
frame #20: 0x000100c4130a cc1plus`expand_all_functions() + 522 at
cgraphunit.c:2118
frame #21: 0x000100c4022e
cc1plus`symbol_table::compile(this=0x0001448050a8) + 990 at
cgraphunit.c:2474
frame #22: 0x000100c414f9
cc1plus`symbol_table::finalize_compilation_unit(this=0x0001448050a8) + 297
at cgraphunit.c:2564
frame #23: 0x000101338cd0 cc1plus`compile_file() + 224 at toplev.c:490
frame #24: 0x000101337318 cc1plus`do_compile() + 328 at toplev.c:1988
frame #25: 0x000101336d48 cc1plus`toplev::main(this=0x7fff5fbff8a8,
argc=30, argv=0x7fff5fbff8e8) + 376 at toplev.c:2096
frame #26: 0x00010185fe20 cc1plus`main(argc=30,
argv=0x7fff5fbff8e8) + 64 at main.c:39
frame #27: 0x7fff862545ad libdyld.dylib`start + 1
frame #28: 0x7fff862545ad libdyld.dylib`start + 1
(lldb)

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[howarth.at.gcc at gmail dot com]

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 patch doesn't solve the bootstrap failure on darwin.

[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546

[howarth.at.gcc at gmail dot com]

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

[Bug bootstrap/70650] bootstrap failure on x86_64 darwin

[howarth.at.gcc at gmail dot com]

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 empty class parameters like C.

* call.c (pass_as_empty_struct, empty_class_arg): New.
(type_passed_as, build_x_va_arg): Use pass_as_empty_struct.
(build_call_a): Use empty_class_arg.
* cp-tree.h (CPTI_EMPTY_STRUCT, empty_struct_type): New.
* decl.c (cxx_init_decl_processing): Create empty_struct_type.

[Bug bootstrap/70650] New: bootstrap failure on x86_64 darwin

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650

Bug ID: 70650
   Summary: bootstrap failure on x86_64 darwin
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  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/gcc6-6.0.0-1/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc6/x86_64-apple-darwin15.5.0/bin/
-B/sw/lib/gcc6/x86_64-apple-darwin15.5.0/lib/ -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.5.0/include -isystem
/sw/lib/gcc6/x86_64-apple-darwin15.5.0/sys-include
-I/sw/src/fink.build/gcc6-6.0.0-1/gcc-6-20160413/libstdc++-v3/../libgcc
-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/include/x86_64-apple-darwin15.5.0
-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc6-6.0.0-1/gcc-6-20160413/libstdc++-v3/libsupc++
-I/sw/include -I/sw/include -std=gnu++11 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=string-inst.lo -g -O2 -c
../../../../../gcc-6-20160413/libstdc++-v3/src/c++11/string-inst.cc 
-fno-common -DPIC -D_GLIBCXX_SHARED -o string-inst.o
In file included from
/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/include/string:53:0,
 from
../../../../../gcc-6-20160413/libstdc++-v3/src/c++11/string-inst.cc:38:
/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/include/bits/basic_string.tcc:
In member function ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag)
[with _FwdIterator = char*; _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]’:
/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/include/bits/basic_string.tcc:206:7:
internal compiler error: in emit_move_insn, at expr.c:3546
   basic_string<_CharT, _Traits, _Alloc>::
   ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:545: recipe for target 'string-inst.lo' failed
make[6]: *** [string-inst.lo] Error 1
make[6]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src/c++11'
Making all in filesystem
make[6]: Entering directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src/filesystem'
make[6]: Nothing to be done for 'all'.
make[6]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src/filesystem'
make[6]: Entering directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src'
make[6]: *** No rule to make target '../src/c++11/libc++11convenience.la',
needed by 'libstdc++-symbols.explist'.  Stop.
make[6]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src'
Makefile:638: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3/src'
Makefile:507: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3'
Makefile:414: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/x86_64-apple-darwin15.5.0/libstdc++-v3'
Makefile:12290: recipe for target 'all-stage1-target-libstdc++-v3' failed
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir'
Makefile:21196: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir'
Makefile:21500: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[howarth.at.gcc at gmail dot com]

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}")
endif()

so they haven't allowed building on 10.6 since
https://github.com/llvm-mirror/compiler-rt/commit/19c8451a0e798abcfd1762fa8196f22b43018d2e#diff-2eeb0237a3e7842df96b4c1280614125

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[howarth.at.gcc at gmail dot com]

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 into gcc so that would
be a red herring. The underlying issue is that the
/usr/lib/system/libdyld.dylib required for the current code to work was only
introduced in 10.7 (darwin11). So a test for the target being darwin10 or
earlier would be the appropriate test for utilizing the legacy code.

[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #4 from Jack Howarth  ---
This issue goes back to http://reviews.llvm.org/D11719

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[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

--- Comment #14 from Jack Howarth  ---
Since this bug impacts platforms that are primary targets, shouldn't it really
be recategorized as a P2 (or least a P3)?

[Bug testsuite/69807] New: FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807

Bug ID: 69807
   Summary: FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times
graphite "number of SCoPs: 0" 1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  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 "number of SCoPs:
0" 1

is failing as follows...

Executing on host: /sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/gcc/ nonpic54649.c  -m32  
-fno-diagnostics-show-caret -fdiagnostics-color=never  -S -o nonpic54649.s   
(timeout = 300)
spawn -ignore SIGHUP /sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/gcc/ nonpic54649.c -m32
-fno-diagnostics-show-caret -fdiagnostics-color=never -S -o nonpic54649.s^M
nonpic54649.c:3:3: error: #error __PIC__^M
compiler exited with status 1
output is:
nonpic54649.c:3:3: error: #error __PIC__^M

FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs:
0" 1

[Bug testsuite/69807] FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 0" 1

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69807

Jack Howarth  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin15
   Host||x86_64-apple-darwin15
  Build||x86_64-apple-darwin15

--- Comment #1 from Jack Howarth  ---
Configured with: ../gcc-6-20160212/configure --prefix=/sw --prefix=/sw/lib/gcc6
--mandir=/sw/share/man --infodir=/sw/lib/gcc6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-6 --with-build-config=bootstrap-debug

using isl 0.14.1

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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
===
--- libstdc++-v3/config/os/bsd/darwin/os_defines.h  (revision 232606)
+++ libstdc++-v3/config/os/bsd/darwin/os_defines.h  (working copy)
@@ -47,4 +47,7 @@
 #define _GLIBCXX_USE_NANOSLEEP 1
 #define _GLIBCXX_USE_SCHED_YIELD 1

+// No support for referencing weak symbols without a definition.
+#define _GLIBCXX_USE_WEAK_REF 0
+
 #endif

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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 incomplete.
You missed the additional required change of...

@@ -385,7 +387,7 @@
 }  \
 void   \
 _ZGTtNSt##NAME##C2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE( \
-CLASS*, const std::__sso_string&) __attribute__((alias \
+CLASS*, const std::__sso_string&) __attribute__((weak, alias  
\
 ("_ZGTtNSt" #NAME  \
   "C1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE")));  \
 void   \

Note however that the compilation of libstdc++-v3/src/c++11/cow-stdexcept.cc on
x86_64-apple-darwin15 does produce warnings of the form...

warning: alias definitions not supported in Mach-O; ignored

and then the bootstrap fails later at...

make[3]: Nothing to be done for `all'.
/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc6/x86_64-apple-darwin15.4.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/libsupc++/.libs

-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/include/x86_64-apple-darwin15.4.0

-I/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc6-6.0.0-1/gcc-6-20160119/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc6-6.0.0-1/darwin_objdir/prev-x86_64-apple-darwin15.4.0/libstdc++-v3/libsupc++/.libs
  -g -O2   -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-no_pie  -o build/genpreds \
build/genpreds.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/hash-table.o build/read-md.o build/errors.o .././libiberty/libiberty.a
Undefined symbols for architecture x86_64:
  "__ITM_RU1", referenced from:
  _txnal_cow_string_C1_for_exceptions(void*, char const*, void*) in
libstdc++.a(cow-stdexcept.o)
  "__ITM_RU8", referenced from:
  _txnal_cow_string_c_str(void const*) in libstdc++.a(cow-stdexcept.o)
  _txnal_sso_string_c_str(void const*) in libstdc++.a(cow-stdexcept.o)
  _txnal_cow_string_D1(void*) in libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::logic_error::logic_error(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for std::logic_error::what() const in
libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::domain_error::domain_error(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::invalid_argument::invalid_argument(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  ...
  "__ITM_addUserCommitAction", referenced from:
  _txnal_cow_string_D1(void*) in libstdc++.a(cow-stdexcept.o)
  "__ITM_memcpyRnWt", referenced from:
  transaction clone for std::logic_error::logic_error(char const*) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::logic_error::logic_error(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for std::domain_error::domain_error(char const*) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::domain_error::domain_error(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for std::invalid_argument::invalid_argument(char
const*) in libstdc++.a(cow-stdexcept.o)
  transaction clone for
std::invalid_argument::invalid_argument(std::__cxx11::basic_string const&) in
libstdc++.a(cow-stdexcept.o)
  transaction clone for std::length_error::length_error(char const*) in
libstdc++.a(cow-stdexcept.o)
  ...
  "__ITM_memcpyRtWn", referenced from:
  _txnal_cow_string_C1_for_exceptions(void*, 

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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 explicit
linkage on libitm to resolve these symbols for the build/genpreds executable.

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #5 from Jack Howarth  ---
(In reply to torvald from comment #4)

> See https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01203.html
> (Not linked to this bug because this bug is about the darwin breakage.)

The commit of that patch didn't resolve the bootstrap failures on
x86_64-apple-darwin15 . The "only weak aliases are supported in this
configuration" errors still block the bootstrap on darwin.

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[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 -Wl,-undefined,dynamic_lookup on the
linkage to avoid linkage errors from the undefined symbols from libitm within
libstdc++.

[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"

[howarth.at.gcc at gmail dot com]

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 Geoff referenced it in a patch, he claimed it was 'effectively
deprecated' in gcc...

https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html

It might be worth checking with the Apple clang developers to see what their
current position is on the feature. I would note that
http://clang.llvm.org/docs/AttributeReference.html has...

A declaration can be used even when deploying back to a platform version prior
to when the declaration was introduced. When this happens, the declaration is
weakly linked, as if the weak_import attribute were added to the declaration. A
weakly-linked declaration may or may not be present a run-time, and a program
can determine whether the declaration is present by checking whether the
address of that declaration is non-NULL.

in the section describing the availability attribute so I guess they still
intend to support into the future.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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 suite? System Integrity Protection on 10.11 will make any 
> > usage of
> 
> No, I've never done that before and try to avoid it if at all possible
> on any platform.
> 
> > DYLD_LIBRARY_PATH by the test suite non-functional so any previously 
> > installed
> > libraries will be used instead of those in the current build directory.
> 
> I wasn't aware of that: what a pity this is an system-wide
> all-or-nothing setting without any way to override it e.g. per session
> with appropriate privilege: makes the system sort of useless for
> combined development and desktop use ;-(
> 

Iain suggested that the required changes for supporting SIP will be along the
lines of...

a) make all libs @rpath/xxx
b) add @loader_path as an rpath to all libs with a local dep.
c) add @executable_path/../lib; ../lib as rpaths
to exes.

> After disabling SIP, I get the same results as you do with your patch.
> 
> Thanks.
> Rainer

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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  ---
> 
> > Iain suggested that the required changes for supporting SIP will be along
> > the lines of...
> > 
> > a) make all libs @rpath/xxx
> > b) add @loader_path as an rpath to all libs with a local dep.
> > c) add @executable_path/../lib; ../lib as
> > rpaths to exes.
> 
> I have a draft for a patch to do this - will try and stick it somewhere
> useful soon.

It certainly would be worthwhile getting some level of support for SIP in gcc 6
as we really don't want to encourage users to disable that feature.

[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69061

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #3 from Jack Howarth  ---
I can reproduce the linkage error when compiling the test case on both gfortran
5.3.0 and current 6.0svn without optimization flags or -O0. However, if pass
-O1/-O2/-O3/-Os/-Ofast, the linkage error disappears. The resulting executables
appear to run successfully on x86_64-apple-darwin15. Note that you can't resort
to -mcmodel=large as it will produce the linkage error...

$ gfortran-fsf-5 -O3 -mcmodel=large TEST_CASE.F03 -o test.x --save-temps
TEST_CASE.s:35:27: error: invalid variant 'PLTOFF'
movabsq $__gfortran_rand@PLTOFF, %rbp
 ^
TEST_CASE.s:38:19: error: invalid variant 'PLTOFF'
movabsq $_memset@PLTOFF, %rbx
 ^
TEST_CASE.s:146:16: error: invalid variant 'PLTOFF'
movabsq $_exp@PLTOFF, %r14
  ^
TEST_CASE.s:261:30: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_open@PLTOFF, %rax
^
TEST_CASE.s:319:31: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_write@PLTOFF, %rdx
 ^
TEST_CASE.s:328:42: error: invalid variant 'PLTOFF'
movabsq $__gfortran_transfer_real_write@PLTOFF, %r9
^
TEST_CASE.s:335:47: error: invalid variant 'PLTOFF'
movabsq $__gfortran_transfer_character_write@PLTOFF, %r10
 ^
TEST_CASE.s:362:36: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_write_done@PLTOFF, %rdx
  ^
TEST_CASE.s:409:31: error: invalid variant 'PLTOFF'
movabsq $__gfortran_set_args@PLTOFF, %rax
 ^
TEST_CASE.s:417:34: error: invalid variant 'PLTOFF'
movabsq $__gfortran_set_options@PLTOFF, %rax
^
Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793#c14 describes the
lack of support for @GOTOFF on darwin so @PLTOFF may be a similar situation.

[Bug libgomp/69046] New: gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69046

Bug ID: 69046
   Summary: gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1
validation test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  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
and verified for '-fopenmp -O3' in the OpenMP3.1_Validation c test suite.

gcc 6.0svn

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:123
S Number of failed tests:  7
S Number of successful tests:  116
S + from this were verified:   95

Normal tests:
N Number of failed tests:  3
N + from this fail compilation:0
N + from this timed out0
N Number of successful tests:  59
N + from this were verified:   47

Orphaned tests:
O Number of failed tests:  4
O + from this fail compilation:0
O + from this timed out0
O Number of successful tests:  57
O + from this were verified:   48

clang 3.8svn (with https://llvm.org/bugs/show_bug.cgi?id=25820#c37 to solve PR
25820)

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:123
S Number of failed tests:  5
S Number of successful tests:  118
S + from this were verified:   112

Normal tests:
N Number of failed tests:  2
N + from this fail compilation:0
N + from this timed out0
N Number of successful tests:  60
N + from this were verified:   55

Orphaned tests:
O Number of failed tests:  3
O + from this fail compilation:0
O + from this timed out0
O Number of successful tests:  58
O + from this were verified:   57

On x86_64-apple-darwin15, I see two additional failures with gcc 6.0svn..

Testing for "omp_get_wtick":
Generating sources .. success
Compiling soures  success
Running test with 8 threads . failed 100% of the tests
+ orphaned mode:
Generating sources .. success
Compiling soures  success
Running test with 8 threads . failed 100% of the tests

and 17 less tests being verified compared to clang 3.8svn.

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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
+++ gcc-6-openmp-validation.log 2015-12-24 13:04:12.0 -0500
@@ -15,11 +15,11 @@
 Testing for "omp_atomic":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 35%
certainty
 Testing for "omp_barrier":
 Generating sources .. success
 Compiling soures  success
@@ -31,19 +31,19 @@
 Testing for "omp_critical":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 Testing for "omp_flush":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 Testing for "omp_for_firstprivate":
 Generating sources .. success
 Compiling soures  success
@@ -59,7 +59,7 @@
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 90%
certainty
+Running test with 8 threads . success .. and verified with 100%
certainty
 Testing for "omp_for_ordered":
 Generating sources .. success
 Compiling soures  success
@@ -71,7 +71,7 @@
 Testing for "omp_for_private":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 95%
certainty
+Running test with 8 threads . success .. and verified with 100%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
@@ -127,11 +127,11 @@
 Testing for "omp_get_wtick":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . failed 100% of the tests
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . failed 100% of the tests
 Testing for "omp_get_wtime":
 Generating sources .. success
 Compiling soures  success
@@ -151,11 +151,11 @@
 Testing for "omp_lock":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 Testing for "omp_master":
 Generating sources .. success
 Compiling soures  success
@@ -167,11 +167,11 @@
 Testing for "omp_nest_lock":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 30%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 Testing for "omp_parallel_copyin":
 Generating sources 

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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 the
underlying bug in the v6.6 based boehm-gc is fixed or boehm-gc in gcc is
rebased on 7.2 or later which doesn't suffer from this bug.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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
> >> both the boehm-gc test suite regressions as well as those in the libjava 
> >> test
> >> suite (which are due to the breakage in boehm-gc used by libjava).
> >
> > Yes it does. This should probably also be done for the 5 branch (I see the 
> > same
> > failures).
> 
> For me (on Mac OS X 10.11.1), the hack fixes the boehm-gc failures, but
> the libjava ones remain.
> 
>   Rainer

Did you remember to install the patched build before attempting to run the
libjava test suite? System Integrity Protection on 10.11 will make any usage of
DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed
libraries will be used instead of those in the current build directory.

Native configuration is x86_64-apple-darwin15.3.0

=== libjava tests ===


Running target unix/-m32
FAIL: PR16923.c compilation

=== libjava Summary for unix/-m32 ===

# of expected passes2580
# of unexpected failures1
# of expected failures  4

Running target unix/-m64
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test

=== libjava Summary for unix/-m64 ===

# of expected passes2574
# of unexpected failures4
# of expected failures  4
# of untested testcases 4

=== libjava Summary ===

# of expected passes5154
# of unexpected failures5
# of expected failures  8
# of untested testcases 4

Compiler version: gcc libjava 
Platform: x86_64-apple-darwin15.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man
--infodir=/sw/lib/gcc6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-6 --with-build-config=bootstrap-debug

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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 regressions as well as those in the libjava test
suite (which are due to the breakage in boehm-gc used by libjava).