public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
Date: Sun, 31 Dec 2023 07:24:02 +0000	[thread overview]
Message-ID: <bug-78352-4-PZ8OI7SJOv@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-78352-4@http.gcc.gnu.org/bugzilla/>

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 ;)

  parent reply	other threads:[~2023-12-31  7:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-78352-4@http.gcc.gnu.org/bugzilla/>
2020-11-07 12:36 ` grobian at gentoo dot org
2020-11-07 12:53 ` iains at gcc dot gnu.org
2020-11-07 16:29 ` egallager at gcc dot gnu.org
2020-11-08  9:11 ` grobian at gentoo dot org
2020-11-08  9:25 ` iains at gcc dot gnu.org
2020-11-09  8:20 ` redi at gcc dot gnu.org
2022-05-13 21:04 ` egor.pugin at gmail dot com
2022-11-05 19:23 ` vital.had at gmail dot com
2023-06-04 19:01 ` vital.had at gmail dot com
2023-06-04 19:28 ` iains at gcc dot gnu.org
2023-12-11 22:55 ` vital.had at gmail dot com
2023-12-11 22:58 ` pinskia at gcc dot gnu.org
2023-12-31  0:58 ` vital.had at gmail dot com
2023-12-31  7:24 ` iains at gcc dot gnu.org [this message]
2024-01-01  0:57 ` egallager at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-78352-4-PZ8OI7SJOv@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).