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
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.
(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.
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
Any news on this front?
(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...
(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)
(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 ..
(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.
(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.
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
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
(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.
(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.
(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.
(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...
(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.
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.
(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.
(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/
(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.
(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?
(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.
(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.
(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 ;)
Cross-referencing against https://github.com/apple/swift-corelibs-libdispatch/issues/765
(In reply to Eric Gallager from comment #25) > Cross-referencing against > https://github.com/apple/swift-corelibs-libdispatch/issues/765 Note that there is some confusion in that issue about if/when Apple's GCC ever had c-blocks support; if someone knowledgeable on the topic could comment there, it'd be helpful.
(In reply to Eric Gallager from comment #26) > (In reply to Eric Gallager from comment #25) > > Cross-referencing against > > https://github.com/apple/swift-corelibs-libdispatch/issues/765 > > Note that there is some confusion in that issue about if/when Apple's GCC > ever had c-blocks support; if someone knowledgeable on the topic could > comment there, it'd be helpful. It is perhaps of academic interest now, but I guess Iain will know for sure.
(In reply to Eric Gallager from comment #25) > Cross-referencing against > https://github.com/apple/swift-corelibs-libdispatch/issues/765 By the way, have you got some example code at hand which can serve as a test? It must not require C/C++ 2011, of course. I can try compiling it on 10.6 with its gcc.
blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after market' support for 10.5). you should be able to find plenty of examples in the Apple Developer doc. This is now becoming more of an issue (e.g. for sanitiser support) there are some APIs that no longer have a non-Blocks version. As with all $hobby things, it takes time ;)
(In reply to Sergey Fedorov from comment #29) > (In reply to Eric Gallager from comment #25) > > Cross-referencing against > > https://github.com/apple/swift-corelibs-libdispatch/issues/765 > > By the way, have you got some example code at hand which can serve as a > test? It must not require C/C++ 2011, of course. > I can try compiling it on 10.6 with its gcc. Check any of the testcases in either of these directories starting with the `block-` prefix: https://github.com/apple-oss-distributions/gcc/tree/e19d86db70127e160b1c32557e0bb80ebc272f92/gcc/testsuite/g%2B%2B.apple https://github.com/apple-oss-distributions/gcc/tree/e19d86db70127e160b1c32557e0bb80ebc272f92/gcc/testsuite/gcc.apple (It's got to be from that particular commit, because that was the last release before Apple stopped shipping the testsuite with their distribution of GCC)
(In reply to Iain Sandoe from comment #30) > blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after > market' support for 10.5). So blocks presumably should work in Rosetta then? Or the support is still Intel-only?