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

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

[grobian at gentoo dot org]

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

Fabian Groffen <grobian at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grobian at gentoo dot org

--- Comment #11 from Fabian Groffen <grobian at gentoo dot org> ---
Is there a patch or WIP somewhere I can try out or attempt to bring forwards?

My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed as I
get some weird "byref undeclared" errors whenever a __block var is encountered.
 I must admit I'm not really well versed with GCC's code.

Thanks

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

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Fabian Groffen from comment #11)
> Is there a patch or WIP somewhere I can try out or attempt to bring forwards?

I need to bring forward my patches to the latest master, will post a link here
when that is done (it won't be soon - mainly because all time is being soaked
up with work on the arm64 port for Apple Silicon). At present, I am also trying
to resolve some of the other (smaller) objective-c issues preventing us from
parsing the system headers.

> My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed
> as I get some weird "byref undeclared" errors whenever a __block var is
> encountered.  I must admit I'm not really well versed with GCC's code.

The apple-4.2.1 branch is, indeed, too far removed from current trunk - and as
far as I understand, we would not be permitted to apply those patches anyway,
since they were not counted as contributed (not present on the FSF servers). 
IANAL - but that's how I understand the rules.

It would be great to have more than one person working on this - I will post
here when the current WIP is published somewhere.

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

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #12)
> (In reply to Fabian Groffen from comment #11)
> > Is there a patch or WIP somewhere I can try out or attempt to bring forwards?
> 
> I need to bring forward my patches to the latest master, will post a link
> here when that is done (it won't be soon - mainly because all time is being
> soaked up with work on the arm64 port for Apple Silicon). At present, I am
> also trying to resolve some of the other (smaller) objective-c issues
> preventing us from parsing the system headers.
> 
> > My attempts at porting the 4.2.1 Apple changes to 10.1 seem to have failed
> > as I get some weird "byref undeclared" errors whenever a __block var is
> > encountered.  I must admit I'm not really well versed with GCC's code.
> 
> The apple-4.2.1 branch is, indeed, too far removed from current trunk - and
> as far as I understand, we would not be permitted to apply those patches
> anyway, since they were not counted as contributed (not present on the FSF
> servers).  IANAL - but that's how I understand the rules.

If we could get in touch with an actual lawyer to review which laws
specifically are getting in the way here, that could be helpful. I won my
election to the New Hampshire State Legislature 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.

> 
> It would be great to have more than one person working on this - I will post
> here when the current WIP is published somewhere.

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

[grobian at gentoo dot org]

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

--- Comment #14 from Fabian Groffen <grobian at gentoo dot org> ---
(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, that could be helpful. I won my
> election to the New Hampshire State Legislature 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.

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

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

[iains at gcc dot 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...

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

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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, that could be helpful. I won my
> election to the New Hampshire State Legislature 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.

I assume the issue is that Apple's patches are GPLv2 and GCC is GPLv3+, and
also that FSF wants copyright assignments for patches to GCC (which is FSF
policy, not law).

Passing laws in NH to allow us to ignore the copyright holder's licence terms
and relicense them as we want would probably violate international conventions,
and would not help in other jurisdictions.

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

[egor.pugin at gmail dot com]

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

--- Comment #17 from Egor Pugin <egor.pugin at gmail dot com> ---
Iain, any chance of publishing your blocks patches as is?

Also what's the status of apple m1 support?
As I understand homebrew's gcc uses your patches, but I met blocks errors when
building cmake in file that includes apple frameworks.

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

[vital.had at gmail dot com]

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

Sergey Fedorov <vital.had at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vital.had at gmail dot com

--- Comment #18 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #15)
> 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...

Any updates ever since? It seems that we need blocks to build libdispatch, and
we need libdispatch on PPC to build some useful stuff.

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

[vital.had at gmail dot com]

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

--- Comment #19 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #1)
> Just to add one note, which is that Apple's gcc-4.2.1 implementation for
> blocks was not actually submitted (and therefore doesn't exist on an FSF
> server);  it's my understanding that means we cannot use / forward port it.
> 
> I'm working on a new version - based on trying to match what clang's current
> code-gen produces.

Is this implementation of some use for us?
https://code.google.com/archive/p/plblocks/

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

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #19)
> (In reply to Iain Sandoe from comment #1)
> > Just to add one note, which is that Apple's gcc-4.2.1 implementation for
> > blocks was not actually submitted (and therefore doesn't exist on an FSF
> > server);  it's my understanding that means we cannot use / forward port it.
> > 
> > I'm working on a new version - based on trying to match what clang's current
> > code-gen produces.
> 
> Is this implementation of some use for us?
> https://code.google.com/archive/p/plblocks/

Not for the compiler - the runtime might be useful for 10.5.

I recently brought my patches forward from GCC-5 => GCC-10 (easier to avoid the
.c => .cc file renaming).  Since we now face some problems with sanitiser
support without blocks, this is moved up the TODO.

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

[vital.had at gmail dot com]

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

--- Comment #21 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #20)
> 
> I recently brought my patches forward from GCC-5 => GCC-10 (easier to avoid
> the .c => .cc file renaming).  Since we now face some problems with
> sanitiser support without blocks, this is moved up the TODO.

Any chance of having it fixed in gcc14?

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

[pinskia at gcc dot gnu.org]

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

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #21)
> Any chance of having it fixed in gcc14?

It is too late to be included in GCC 14, GCC is in stage 3 already, that is no
new features can be included that was not posted before a specific date. See
https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and
https://gcc.gnu.org/develop.html about the timing there.

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

[vital.had at gmail dot com]

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

--- Comment #23 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Sergey Fedorov from comment #21)
> > Any chance of having it fixed in gcc14?
> 
> It is too late to be included in GCC 14, GCC is in stage 3 already, that is
> no new features can be included that was not posted before a specific date.
> See https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and
> https://gcc.gnu.org/develop.html about the timing there.

Oh…

Can new features be added into minor releases, like 14.x?

P. S. On a side note, I delayed forever my fixes for gfortran on PowerPC, will
return to that soonish, so we can get in into the master in a reasonable time.

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

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #23)
> (In reply to Andrew Pinski from comment #22)
> > (In reply to Sergey Fedorov from comment #21)
> > > Any chance of having it fixed in gcc14?
> > 
> > It is too late to be included in GCC 14, GCC is in stage 3 already, that is
> > no new features can be included that was not posted before a specific date.
> > See https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and
> > https://gcc.gnu.org/develop.html about the timing there.
> 
> Oh…
> 
> Can new features be added into minor releases, like 14.x?

No. The general rule is that we only fix regressions and documentation/tests on
release branches.  As Darwin maintainer, I include fixes for build/ABI problems
in back-ports (where they only effect Darwin).

Any new feature like blocks support would be much more invasive than that, so
definitely have to wait for GCC-15.

Like other "vendors", I maintain external branches for Darwin that have more
relaxed rules - allowing port-critical back ports that would not be acceptable
upstream,

However, first we have to complete this work and bring it forward to trunk ..
then we can worry about back ports to older branched ;)

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

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/apple/sw
                   |                            |ift-corelibs-libdispatch/is
                   |                            |sues/765

--- Comment #25 from Eric Gallager <egallager at gcc dot gnu.org> ---
Cross-referencing against
https://github.com/apple/swift-corelibs-libdispatch/issues/765