From: Lynne <dev@lynne.ee>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Date: Thu, 8 Feb 2024 20:46:15 +0100 (CET)
Message-ID: <Nq9FPWC--3-9@lynne.ee> (raw)
In-Reply-To: <ed8a04d5-3568-4794-bf29-0262c9c57cec@gmail.com>
Feb 8, 2024, 20:05 by jamrial@gmail.com:
> On 2/8/2024 3:52 PM, Sean McGovern wrote:
>
>> Hi developers,
>>
>> On Wed, Feb 7, 2024, 23:30 Jean-Baptiste Kempf <jb@videolan.org> wrote:
>>
>>> Hello,
>>>
>>> On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
>>>
>>>>> There were simply no objections to moving to C11.
>>>>> The C17 plan came about later because it has important bugfixes.
>>>>> It doesn't really matter as compilers backported the new behaviour to
>>>>>
>>> C11
>>>
>>>>> (or rather, they consistently had the same behaviour, but now it became
>>>>>
>>> a standard).
>>>
>>>>>
>>>>>
>>>>
>>>> There were no objections to C11, however C17 was brought up and there
>>>> were objections that it's likely too soon and I believe JB proposed
>>>> holding off for a year on C17 (while adopting C11 immediately), which
>>>>
>>>
>>> My recommendation is still this:
>>> - move to C11 now
>>> - activate C17 on some Fate/CI targets
>>> - recommend C17 compilers modes
>>> - move to C17 at this mid-year when 7.1 is branched (LTS if we follow our
>>> plans)
>>>
>>
>>
>> I like this approach. It's a shame we can't get metrics on who might be
>> genuinely affected by a direct move to C17.
>>
>> I'd be more than willing to host one or more FATE nodes with C17 turned on.
>> Do let me know if this is desirable.
>>
>
> At least for GCC, -std=c11 is the same as -std=c17 except for the __STDC_VERSION__ value. As in, apparently all the fixes are implemented either way. And as far as i understand it, we would require c11 but use c17 if present (Meaning, test std=c17, fallback to std=c11, abort if not possible), so all FATE instances using a relatively recent compiler will invariably use c17.
>
> What we would need is instances with old compilers, pre-2017, to get actual c11 testing.
>
We have plenty of old compilers on FATE, don't we?
I think the point of bumping the build-time requirements is to get rid of them,
and maybe we could use the chance to also get higher-quality metrics on
whether we can use the chance to reenable stuff like tree vectorization again
without old compilers miscompiling.
I could live with C11 for 7.0, but I would prefer to bump to C17 soon after
this release is made, rather than waiting for the middle of the year to have
to discuss this again.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-08 19:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 19:54 [FFmpeg-devel] [PATCH 1/2] lavc/refstruct: do not use max_align_t on MSVC Anton Khirnov
2024-02-05 19:54 ` [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17 Anton Khirnov
2024-02-05 20:12 ` James Almer
2024-02-05 20:13 ` Anton Khirnov
2024-02-05 20:13 ` Devin Heitmueller
2024-02-05 20:30 ` Anton Khirnov
2024-02-05 20:33 ` James Almer
2024-02-05 20:40 ` Devin Heitmueller
2024-02-07 9:50 ` Anton Khirnov
2024-02-07 16:15 ` Devin Heitmueller
2024-02-07 16:36 ` Anton Khirnov
2024-02-05 20:53 ` Niklas Haas
2024-02-09 11:22 ` Dominik 'Rathann' Mierzejewski
2024-02-09 12:04 ` Kevin Wheatley
2024-02-05 20:20 ` Lynne
2024-02-05 20:27 ` Michael Niedermayer
2024-02-05 20:31 ` Anton Khirnov
2024-02-05 20:45 ` Michael Niedermayer
2024-02-07 9:55 ` Anton Khirnov
[not found] ` <2E73439B-3AE5-46FC-80FB-2D375FD852C5@cosmin.at>
2024-02-07 18:52 ` Cosmin Stejerean via ffmpeg-devel
2024-02-07 19:27 ` Lynne
[not found] ` <1CBFE199-B1ED-47B5-BD97-7DA715EAB55B@cosmin.at>
2024-02-07 21:10 ` Cosmin Stejerean via ffmpeg-devel
2024-02-07 21:19 ` James Almer
2024-02-08 7:15 ` Rémi Denis-Courmont
2024-02-08 10:42 ` Andreas Rheinhardt
2024-02-07 21:48 ` Lynne
[not found] ` <8C790A7E-A236-4413-A4EB-AFE2F91E96A8@cosmin.at>
2024-02-08 0:36 ` Cosmin Stejerean via ffmpeg-devel
2024-02-08 4:29 ` Jean-Baptiste Kempf
2024-02-08 18:52 ` Sean McGovern
2024-02-08 19:05 ` James Almer
2024-02-08 19:46 ` Lynne [this message]
2024-02-05 20:55 ` Niklas Haas
2024-02-05 22:22 ` Stefano Sabatini
2024-02-07 9:53 ` Anton Khirnov
2024-02-06 6:50 ` Diederick C. Niehorster
2024-02-06 12:03 ` Lynne
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=Nq9FPWC--3-9@lynne.ee \
--to=dev@lynne.ee \
--cc=ffmpeg-devel@ffmpeg.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
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git