[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Fabian Groffen from comment #14)
> (In reply to Eric Gallager from comment #13)
> > If we could get in touch with an actual lawyer to review which laws
> > specifically are getting in the way here,

I would expect that the determination has been made by the FSF lawyers (but I
am not an authority here, just repeating the policy put to me when I started
work on the Darwin port, years ago).

> that could be helpful. I won my
> > election to the New Hampshire State Legislature 

congrats!

>>so if there's any
> > legislation I could pass to make it legal to apply those patches here in NH,
> > I'd love to know how to write it.

IMO the technical issues with reusing 4.2.1 code are so significant that it
would be a poor use of your time chasing a way to include stuff that we'd need
to rewrite anyway (see below)

> FWIW: if Iain wrote a new patch, then we don't need Apple's original work
> which from my experience, frankly is messy.

Indeed, it isn't suitable for the current source base - there have been a lot
of changes since 4.2.1.  As a secondary consideration, I also want to move
Objective-C style metadata generation until after LTO has run (and Apple blocks
also makes use of that style meta-data).

>  There's lots of stuff in there
> intertwined, so going by a specification e.g. Clang's
> (https://clang.llvm.org/docs/BlockLanguageSpec.html) is probably the best
> way forward in any case.

Which is what I was doing + 1:1 comparison with clang's output ( on the grounds
that the ABI is defined by the actual output regardless of what the
documentation says ;) ) 

Sorry that there hasn't been much progress on this - it *was* top of my GCC11
TODO list, and then Apple Si. came along and torpedoed that...