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, MOOSE 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.
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.
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.