Bug 78352 - GCC lacks support for the Apple "blocks" extension to the C family of languages
Summary: GCC lacks support for the Apple "blocks" extension to the C family of languages
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.0
: P3 enhancement
Target Milestone: ---
Assignee: Iain Sandoe
URL:
Keywords:
Depends on:
Blocks: 90709
  Show dependency treegraph
 
Reported: 2016-11-14 21:05 UTC by Eric Gallager
Modified: 2021-06-19 17:04 UTC (History)
5 users (show)

See Also:
Host: *darwin*
Target: *darwin*
Build: *darwin*
Known to work:
Known to fail:
Last reconfirmed: 2016-11-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Gallager 2016-11-14 21:05:15 UTC
In bug 78267 Iain suggested to open a separate bug for the issue of missing Apple-blocks support in FSF GCC, so that's what this bug is. Here is an example of code that is currently rejected due to lack of support for this feature:

typedef void (^os_trace_payload_t)(xpc_object_t xdict);

In Apple's gcc and clang, support for blocks can be enabled with the -fblocks flag, and can be detected by the presence of the __BLOCKS__ preprocessor macro. This extension applies to all members of the C family: C, C++, Objective C, and Objective C++. 

Further information:
https://gcc.gnu.org/ml/gcc/2009-09/msg00277.html (and the rest of the thread)
https://gcc.gnu.org/ml/gcc/2013-11/msg00039.html (likewise, & rest of thread)
Bug 63651
http://clang.llvm.org/docs/BlockLanguageSpec.html
http://clang.llvm.org/docs/Block-ABI-Apple.html
http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1370.pdf
https://en.wikipedia.org/wiki/Blocks_%28C_language_extension%29
Comment 1 Iain Sandoe 2016-11-18 11:48:21 UTC
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.
Comment 2 Eric Gallager 2017-11-02 00:41:15 UTC
(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.

Changing status to ASSIGNED then since you put yourself as the assignee.
Comment 3 Eric Gallager 2018-01-07 19:47:18 UTC
Blocks had to be removed from the Objective-C sources in Emacs due to this bug: https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-12/msg00301.html
Comment 4 René J.V. Bertin 2018-04-02 14:17:18 UTC
Any news on this front?
Comment 5 Eric Gallager 2018-04-10 04:17:03 UTC
(In reply to René J.V. Bertin from comment #4)
> Any news on this front?

Last I heard from Iain he was still having to deal with water damage to his office...
Comment 6 Eric Gallager 2018-12-15 03:38:47 UTC
(In reply to Eric Gallager from comment #5)
> (In reply to René J.V. Bertin from comment #4)
> > Any news on this front?
> 
> Last I heard from Iain he was still having to deal with water damage to his
> office...

He seems to be back now, but dealing with lower-hanging fruit in his backlog at the moment. (I really wish I knew as much about the Darwin port as he does so I could help reduce its "bus factor", but unfortunately I haven't been able to focus hard enough to sit down and really learn it)
Comment 7 Iain Sandoe 2018-12-15 08:41:49 UTC
(In reply to Eric Gallager from comment #6)
> (In reply to Eric Gallager from comment #5)
> > (In reply to René J.V. Bertin from comment #4)
> > > Any news on this front?
> > 
> > Last I heard from Iain he was still having to deal with water damage to his
> > office...
> 
> He seems to be back now, but dealing with lower-hanging fruit in his backlog
> at the moment. 

The focus is on wrong-code and regression bugs at the moment (not necessarily lowest-hanging fruit)

Apropos this enhancement:
1) My last set of working patches was against 4.9/5 - so they need to be forward-ported.
2) There is a design ;-) the reason this is assigned...
3) This would involve changes to c-family FE and some ME additions, so you can be sure it is not relevant until 10 stage 1 at the earliest.

> (I really wish I knew as much about the Darwin port as he
> does so I could help reduce its "bus factor", but unfortunately I haven't
> been able to focus hard enough to sit down and really learn it)

There is a lot of testsuite noise some of which probably *is* low-hanging fruit (places where there are Linux-isms in the test cases which simply need the Darwin equivalent) - Darwin folks *you* can test/analyse/categorise these, whereas the folks without a Darwin box cannot - so please go at it!  JFTR, I started with testsuite fixes ..
Comment 8 Eric Gallager 2019-03-16 19:15:50 UTC
(In reply to Iain Sandoe from comment #7)
> (In reply to Eric Gallager from comment #6)
> > (In reply to Eric Gallager from comment #5)
> > > (In reply to René J.V. Bertin from comment #4)
> > > > Any news on this front?
> > > 
> > > Last I heard from Iain he was still having to deal with water damage to his
> > > office...
> > 
> > He seems to be back now, but dealing with lower-hanging fruit in his backlog
> > at the moment. 
> 
> The focus is on wrong-code and regression bugs at the moment (not
> necessarily lowest-hanging fruit)

As it ought to be for stage 4... 

> 
> Apropos this enhancement:
> 1) My last set of working patches was against 4.9/5 - so they need to be
> forward-ported.
> 2) There is a design ;-) the reason this is assigned...
> 3) This would involve changes to c-family FE and some ME additions, so you
> can be sure it is not relevant until 10 stage 1 at the earliest.
> 
> > (I really wish I knew as much about the Darwin port as he
> > does so I could help reduce its "bus factor", but unfortunately I haven't
> > been able to focus hard enough to sit down and really learn it)
> 
> There is a lot of testsuite noise some of which probably *is* low-hanging
> fruit (places where there are Linux-isms in the test cases which simply need
> the Darwin equivalent) - Darwin folks *you* can test/analyse/categorise
> these, whereas the folks without a Darwin box cannot - so please go at it! 
> JFTR, I started with testsuite fixes ..

my latest testsuite results are here: https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg01042.html

A diff from my previous run can be found here: https://github.com/cooljeanius/gcc_bugs/blob/master/testsuite_logs/SnowLeopard/180905_to_190209.diff

Some of the noise in the diff is from switching to bootstrapping using your patched cctools and your gcc 5 binaries, instead of my previous build of gcc trunk.
Comment 9 Iain Sandoe 2019-03-16 20:11:47 UTC
(In reply to Eric Gallager from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Eric Gallager from comment #6)
> > > (In reply to Eric Gallager from comment #5)
> > > > (In reply to René J.V. Bertin from comment #4)
> > > > > Any news on this front?

> > There is a lot of testsuite noise some of which probably *is* low-hanging
> > fruit (places where there are Linux-isms in the test cases which simply need
> > the Darwin equivalent) - Darwin folks *you* can test/analyse/categorise
> > these, whereas the folks without a Darwin box cannot - so please go at it! 
> > JFTR, I started with testsuite fixes ..
> 
> my latest testsuite results are here:
> https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg01042.html

looks "about right" (I have fixes for some of the fails - just need to get some cycles on it).

> A diff from my previous run can be found here:
> https://github.com/cooljeanius/gcc_bugs/blob/master/testsuite_logs/
> SnowLeopard/180905_to_190209.diff
> 
> Some of the noise in the diff is from switching to bootstrapping using your
> patched cctools and your gcc 5 binaries, instead of my previous build of gcc
> trunk.

Well, there's a very large interval in the test-diff, so it's quite hard to draw too much conclusion - but the newer cctools *does* report more diagnostics than the Xcode 3.2.6 set.

- this isn't an ideal place for general test discussion - perhaps identify if test fails have already been seen and update the "last reconfirmed" if they have, or file a new PR if none exists.
Comment 10 Eric Gallager 2019-11-08 02:29:48 UTC
This bug means we now have to leave out a part of libsanitizer that uses blocks:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00262.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00268.html
Comment 11 Fabian Groffen 2020-11-07 12:36:17 UTC
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
Comment 12 Iain Sandoe 2020-11-07 12:53:45 UTC
(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.
Comment 13 Eric Gallager 2020-11-07 16:29:21 UTC
(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.
Comment 14 Fabian Groffen 2020-11-08 09:11:50 UTC
(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.
Comment 15 Iain Sandoe 2020-11-08 09:25:23 UTC
(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...
Comment 16 Jonathan Wakely 2020-11-09 08:20:44 UTC
(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.