[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Eric Gallager changed: What|Removed |Added See Also||https://github.com/apple/sw ||ift-corelibs-libdispatch/is ||sues/765 --- Comment #25 from Eric Gallager --- Cross-referencing against https://github.com/apple/swift-corelibs-libdispatch/issues/765
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #24 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #23 from Sergey Fedorov --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #22 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #21 from Sergey Fedorov --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #20 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #19 from Sergey Fedorov --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #18 from Sergey Fedorov --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #17 from Egor Pugin --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #16 from Jonathan Wakely --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #15 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #14 from Fabian Groffen --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #13 from Eric Gallager --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #12 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Fabian Groffen changed: What|Removed |Added CC||grobian at gentoo dot org --- Comment #11 from Fabian Groffen --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #10 from Eric Gallager --- 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
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #9 from Iain Sandoe --- (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.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #8 from Eric Gallager --- (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.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #7 from Iain Sandoe --- (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 ..
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #6 from Eric Gallager --- (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)
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #5 from Eric Gallager --- (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...
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 René J.V. Bertin changed: What|Removed |Added CC||rjvbertin at gmail dot com --- Comment #4 from René J.V. Bertin --- Any news on this front?
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #3 from Eric Gallager --- 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
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (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.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Iain Sandoe changed: What|Removed |Added Target||*darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-18 CC||iains at gcc dot gnu.org Host||*darwin* Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Build||*darwin* --- Comment #1 from Iain Sandoe --- 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.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Richard Biener changed: What|Removed |Added Severity|normal |enhancement
