[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-18 Thread fink at snaggledworks dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #85 from fink at snaggledworks dot com ---
(In reply to Zaak from comment #84)
> Ian, Jurgen, et al.,
> 
> Thanks for your hard work getting the patch created and validated!
> 
> I'm a mac Homebrew maintainer, and was hoping to get a patch into the GCC-8
> formula sooner rather than later as this Xcode regression makes building
> certain software e.g., libMesh[1], MOOSE[2] impossible (or difficult,
> requiring patching that might be breaking things).
> 
> Is there a patch somewhere that resolves this and will apply cleanly to a
> GCC 8.3 tarball? I'd like to test the backport, and get the patch ready to
> include in brewed GCCs.
> 
> If I revision bump the formula after including the patch, our CI system will
> rebuild all dependent formulae which should be quite a thorough validation
> of the patch.
> 
> Apologies if an 8.3 patch went by already, if so, please point me in the
> right direction.
> 
> Cheers!
> -Izaak "Zaak" Beekman

Zaak,
I have patches for Fink for gcc5-gcc8 release tarballs. I'm waiting for the
gcc5 build to finish before I make a public commit, which should be tonight.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-04-17 Thread fink at snaggledworks dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #79 from fink at snaggledworks dot com ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
> 
> So I have an answer about the language implications.
> 
> Any C++ program containing _Atomic is using a reserved identifier, and so is
> "ill-formed no diagnostic required", per [lex.name]/3
> 
> Therefore, it's standards-conforming for a [C++] implementation to make such
> identifiers keywords (as GCC does for __attribute__, for example)
> 
> Apparently, this is intentional extension and is only one of a longer list
> of such keywords that clang++ accepts.
> 
> 
> 
> Since, according to the discussion above, this is not a bug in the compiler
> but rather in using a non-portable extension, perhaps we should not expect
> any change to the headers.
> 
> 
> 
> The patch attached include the generated files, and I'd be grateful if folks
> would test it (right now I have limited access to Darwin test boxen, but it
> seems to DTRT for me) - I will post to @patches, but leave commit until it's
> confirmed that it's working.

A little late to the party, but this revised patch worked for me on
10.4.4/Xcode10.2 with gcc8.3.0, gcc7.4.0, and gcc6.5.0.  fftw3-3.3.8 built and
passed all tests against the patched gcc8 and gcc7.  cernlib built against the
patched gcc6.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-09 Thread fink at snaggledworks dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

fink at snaggledworks dot com changed:

   What|Removed |Added

 CC||fink at snaggledworks dot com

--- Comment #52 from fink at snaggledworks dot com ---
(In reply to Iain Sandoe from comment #43)
> Created attachment 46110 [details]
> Proof-of-principle path
> 
> Does this work for you?
>  - my local testing says it generates the right wrapped include file.
> 
> (perhaps the constraint on darwin version was too tight in Erik's case)

I applied this patch to the 8.3.0 source as built using the Fink gcc8 package
(with minor tweaks so it would apply cleanly), and gcc-8.3.0 now built fine on
macOS 10.14.4 with Xcode10.2.