Towards GNU11
Hi!
I'd like to kick off a discussion about moving the default standard
for C from gnu89 to gnu11.
This really shouldn't be much of a surprise: the docs mention that
gnu11 is intended future default for a year now. I would presume now
is a good time to make this move: together with the new naming scheme
this should make GCC more modern (C89 really is as old as the hills).
And we're still in stage1.
Prerequisites should be largely complete at this point:
- we have -Wc90-c99-compat option that warns about features not present
in ISO C90, but present in ISO C99,
- we have -Wc99-c11-compat option that warns about features not present
in ISO C99, but present in ISO C11,
- the testsuite has been adjusted so all the test that pass with gnu89
default should pass with gnu11 default as well (see my recent batch
of cleanup patches). This unfortunately isn't correct for all archs,
I just don't have enough resources to test everything. But generally
the fallout from moving to gnu11 is easy to fix: just add proper decls
and return types (to fix defaulting to int), or for inline stuff use
-fgnu89-inline/gnu_inline attribute. I'd appreciate testing on other
architectures than x86_64/ppc64.
The things I had to fix in the testsuite nicely reflect what we can expect
in the real life: mostly bunch of new warnings about missing declarations
and defaulting to int (this is probably going to be a pain with -Werror,
but I feel that people really should write proper declarations), different
inline semantics (in C99 semantics, the TU has to have the body of the inline
function etc.), new "return with no value, in function returning non-void"
warnings. Different rules for constant expressions, the fact that in C90
non-lvalue arrays do not decay to pointers, slightly different rules for
compatible types (?) might come in game as well.
In turn, you can use all C99 and C11 features even with -pedantic.
Comments?
Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
2014-10-07 Marek Polacek
* doc/invoke.texi: Update to reflect that GNU11 is the default
mode for C.
* c-common.h (c_language_kind): Update comment.
c-family/
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 1e3477f..a895084 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -445,7 +445,7 @@ struct GTY(()) sorted_fields_type {
typedef enum c_language_kind
{
- clk_c= 0,/* C90, C94 or C99 */
+ clk_c= 0,/* C90, C94, C99 or C11 */
clk_objc = 1,/* clk_c with ObjC features. */
clk_cxx = 2,/* ANSI/ISO C++ */
clk_objcxx = 3 /* clk_cxx with ObjC features. */
diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
index 3f295d8..eb078e3 100644
--- gcc/c-family/c-opts.c
+++ gcc/c-family/c-opts.c
@@ -250,6 +250,9 @@ c_common_init_options (unsigned int decoded_options_count,
if (c_language == clk_c)
{
+ /* The default for C is gnu11. */
+ set_std_c11 (false /* ISO */);
+
/* If preprocessing assembly language, accept any of the C-family
front end options since the driver may pass them through. */
for (i = 1; i < decoded_options_count; i++)
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 5fe7e15..fa84ed4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -1692,8 +1692,7 @@ interfaces) and L (Analyzability). The name @samp{c1x}
is deprecated.
@item gnu90
@itemx gnu89
-GNU dialect of ISO C90 (including some C99 features). This
-is the default for C code.
+GNU dialect of ISO C90 (including some C99 features).
@item gnu99
@itemx gnu9x
@@ -1701,8 +1700,8 @@ GNU dialect of ISO C99. The name @samp{gnu9x} is
deprecated.
@item gnu11
@itemx gnu1x
-GNU dialect of ISO C11. This is intended to become the default in a
-future release of GCC. The name @samp{gnu1x} is deprecated.
+GNU dialect of ISO C11. This is the default for C code.
+The name @samp{gnu1x} is deprecated.
@item c++98
@itemx c++03
Marek
Re: Towards GNU11
On Tue, 7 Oct 2014, Marek Polacek wrote:
> Hi!
>
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.
>
> This really shouldn't be much of a surprise: the docs mention that
> gnu11 is intended future default for a year now. I would presume now
> is a good time to make this move: together with the new naming scheme
> this should make GCC more modern (C89 really is as old as the hills).
> And we're still in stage1.
>
> Prerequisites should be largely complete at this point:
> - we have -Wc90-c99-compat option that warns about features not present
> in ISO C90, but present in ISO C99,
> - we have -Wc99-c11-compat option that warns about features not present
> in ISO C99, but present in ISO C11,
> - the testsuite has been adjusted so all the test that pass with gnu89
> default should pass with gnu11 default as well (see my recent batch
> of cleanup patches). This unfortunately isn't correct for all archs,
> I just don't have enough resources to test everything. But generally
> the fallout from moving to gnu11 is easy to fix: just add proper decls
> and return types (to fix defaulting to int), or for inline stuff use
> -fgnu89-inline/gnu_inline attribute. I'd appreciate testing on other
> architectures than x86_64/ppc64.
>
> The things I had to fix in the testsuite nicely reflect what we can expect
> in the real life: mostly bunch of new warnings about missing declarations
> and defaulting to int (this is probably going to be a pain with -Werror,
> but I feel that people really should write proper declarations), different
> inline semantics (in C99 semantics, the TU has to have the body of the inline
> function etc.), new "return with no value, in function returning non-void"
> warnings. Different rules for constant expressions, the fact that in C90
> non-lvalue arrays do not decay to pointers, slightly different rules for
> compatible types (?) might come in game as well.
>
> In turn, you can use all C99 and C11 features even with -pedantic.
>
> Comments?
I think it makes sense to do this (and I expect C++ will follow
with defaulting to -std=c++11 once the ABI stuff has settled).
Of course it would be nice to look at the actual fallout in
a whole-distribution rebuild...
Thanks,
Richard.
> Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
>
> 2014-10-07 Marek Polacek
>
> * doc/invoke.texi: Update to reflect that GNU11 is the default
> mode for C.
> * c-common.h (c_language_kind): Update comment.
> c-family/
> * c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.
>
> diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
> index 1e3477f..a895084 100644
> --- gcc/c-family/c-common.h
> +++ gcc/c-family/c-common.h
> @@ -445,7 +445,7 @@ struct GTY(()) sorted_fields_type {
>
> typedef enum c_language_kind
> {
> - clk_c = 0,/* C90, C94 or C99 */
> + clk_c = 0,/* C90, C94, C99 or C11 */
>clk_objc = 1,/* clk_c with ObjC features. */
>clk_cxx= 2,/* ANSI/ISO C++ */
>clk_objcxx = 3 /* clk_cxx with ObjC features. */
> diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
> index 3f295d8..eb078e3 100644
> --- gcc/c-family/c-opts.c
> +++ gcc/c-family/c-opts.c
> @@ -250,6 +250,9 @@ c_common_init_options (unsigned int decoded_options_count,
>
>if (c_language == clk_c)
> {
> + /* The default for C is gnu11. */
> + set_std_c11 (false /* ISO */);
> +
>/* If preprocessing assembly language, accept any of the C-family
>front end options since the driver may pass them through. */
>for (i = 1; i < decoded_options_count; i++)
> diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
> index 5fe7e15..fa84ed4 100644
> --- gcc/doc/invoke.texi
> +++ gcc/doc/invoke.texi
> @@ -1692,8 +1692,7 @@ interfaces) and L (Analyzability). The name @samp{c1x}
> is deprecated.
>
> @item gnu90
> @itemx gnu89
> -GNU dialect of ISO C90 (including some C99 features). This
> -is the default for C code.
> +GNU dialect of ISO C90 (including some C99 features).
>
> @item gnu99
> @itemx gnu9x
> @@ -1701,8 +1700,8 @@ GNU dialect of ISO C99. The name @samp{gnu9x} is
> deprecated.
>
> @item gnu11
> @itemx gnu1x
> -GNU dialect of ISO C11. This is intended to become the default in a
> -future release of GCC. The name @samp{gnu1x} is deprecated.
> +GNU dialect of ISO C11. This is the default for C code.
> +The name @samp{gnu1x} is deprecated.
>
> @item c++98
> @itemx c++03
>
> Marek
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: Towards GNU11
On Wed, Oct 08, 2014 at 09:16:18AM +0200, Richard Biener wrote: > I think it makes sense to do this (and I expect C++ will follow > with defaulting to -std=c++11 once the ABI stuff has settled). Thanks. Moving to -std=c++11 would be cool! > Of course it would be nice to look at the actual fallout in > a whole-distribution rebuild... Yeah, I'm worried about that. Many packages are using -std=gnu99 (e.g. glibc, elfutils, maybe emacs) and these won't be affected at all. But e.g. gdb/binutils use the default standard I think. I wonder about Linux kernel. And of course, C++ packages should be out of the picture here. Marek
Re: Towards GNU11
On 10/07/14 15:07, Marek Polacek wrote: Hi! I'd like to kick off a discussion about moving the default standard for C from gnu89 to gnu11. This really shouldn't be much of a surprise: the docs mention that gnu11 is intended future default for a year now. I would presume now is a good time to make this move: together with the new naming scheme this should make GCC more modern (C89 really is as old as the hills). And we're still in stage1. Prerequisites should be largely complete at this point: - we have -Wc90-c99-compat option that warns about features not present in ISO C90, but present in ISO C99, - we have -Wc99-c11-compat option that warns about features not present in ISO C99, but present in ISO C11, - the testsuite has been adjusted so all the test that pass with gnu89 default should pass with gnu11 default as well (see my recent batch of cleanup patches). This unfortunately isn't correct for all archs, I just don't have enough resources to test everything. But generally the fallout from moving to gnu11 is easy to fix: just add proper decls and return types (to fix defaulting to int), or for inline stuff use -fgnu89-inline/gnu_inline attribute. I'd appreciate testing on other architectures than x86_64/ppc64. The things I had to fix in the testsuite nicely reflect what we can expect in the real life: mostly bunch of new warnings about missing declarations and defaulting to int (this is probably going to be a pain with -Werror, but I feel that people really should write proper declarations), different inline semantics (in C99 semantics, the TU has to have the body of the inline function etc.), new "return with no value, in function returning non-void" warnings. Different rules for constant expressions, the fact that in C90 non-lvalue arrays do not decay to pointers, slightly different rules for compatible types (?) might come in game as well. In turn, you can use all C99 and C11 features even with -pedantic. Comments? Regtested/bootstrapped on powerpc64-linux and x86_64-linux. 2014-10-07 Marek Polacek * doc/invoke.texi: Update to reflect that GNU11 is the default mode for C. * c-common.h (c_language_kind): Update comment. c-family/ * c-opts.c (c_common_init_options): Make -std=gnu11 the default for C. I like it. And one could reasonably argue that now is the time to change since that maximizes the time for folks to find broken code. I'd go so far as to conditionally approve -- if other maintainers don't shout out in the next week or so against, then I feel this should go forward. I know it's really early, but a "porting to ..." document ought to be started and have something in it about these changes. Both how to fix the broken code or how to go back to c89. Jeff
Re: Towards GNU11
On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote: > I like it. And one could reasonably argue that now is the time to change > since that maximizes the time for folks to find broken code. Yep, this is definitely stage1 stuff. We still have a few weeks, but I wouldn't want to rush such a change in the nick of time. > I'd go so far as to conditionally approve -- if other maintainers don't > shout out in the next week or so against, then I feel this should go > forward. Thanks. I will wait at least until the end of next week. I'd like to hear from Joseph ;). > I know it's really early, but a "porting to ..." document ought to be > started and have something in it about these changes. Both how to fix the > broken code or how to go back to c89. Absolutely. I'll start something up once it's in. I feel that especially the inline semantics change should be addressed therein. Marek
Re: Towards GNU11
Am 08.10.2014 um 09:16 schrieb Richard Biener: > On Tue, 7 Oct 2014, Marek Polacek wrote: > I think it makes sense to do this (and I expect C++ will follow > with defaulting to -std=c++11 once the ABI stuff has settled). > > Of course it would be nice to look at the actual fallout in > a whole-distribution rebuild... I can certainly do that, once stage1 is finished, hopefully for more than x86 architectures. What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Matthias
Re: Towards GNU11
On 10/09/2014 08:45 AM, Matthias Klose wrote: What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Yes. Jason
Re: Towards GNU11
On Thu, 9 Oct 2014, Marek Polacek wrote: > On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote: > > I like it. And one could reasonably argue that now is the time to change > > since that maximizes the time for folks to find broken code. > > Yep, this is definitely stage1 stuff. We still have a few weeks, but > I wouldn't want to rush such a change in the nick of time. > > > I'd go so far as to conditionally approve -- if other maintainers don't > > shout out in the next week or so against, then I feel this should go > > forward. > > Thanks. I will wait at least until the end of next week. > > I'd like to hear from Joseph ;). I approve of the change in default (I just don't think it's a change to make on my say-so alone). -- Joseph S. Myers jos...@codesourcery.com
Re: Towards GNU11
On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote: > I'd like to kick off a discussion about moving the default standard > for C from gnu89 to gnu11. I endorse the change of default. > The things I had to fix in the testsuite nicely reflect what we can expect > in the real life: A wiki page that has the types of changes people hit in real code with how to fix it, would be useful, helpful. Might be nice to have this in the document, but, don’t know if people want to do that much work. The wiki site is nice, as if others do world builds, then can add what ever they hit in easily, which then makes that even more complete. This is a nice to have, I don’t think the work going in should be gated on this. > Comments? Two comment: Thank you for all your hard work. Yes please.
Re: Towards GNU11
On Thu, Oct 09, 2014 at 02:34:51PM -0700, Mike Stump wrote: > On Oct 7, 2014, at 2:07 PM, Marek Polacek wrote: > > I'd like to kick off a discussion about moving the default standard > > for C from gnu89 to gnu11. > > I endorse the change of default. Thanks for chiming in. > A wiki page that has the types of changes people hit in real code with how to > fix it, would be useful, helpful. Might be nice to have this in the > document, but, don’t know if people want to do that much work. The wiki site > is nice, as if others do world builds, then can add what ever they hit in > easily, which then makes that even more complete. This is a nice to have, I > don’t think the work going in should be gated on this. Yeah. I plan to write something into the "porting to" document. > Two comment: > > Thank you for all your hard work. > > Yes please. Thank you very much! Marek
Re: Towards GNU11
On Tue, Oct 07, 2014 at 11:07:56PM +0200, Marek Polacek wrote: > I'd like to kick off a discussion about moving the default standard > for C from gnu89 to gnu11. The consensus seems to be to go forward with this change. I will commit the patch in 24 hours unless I hear objections. Thanks, Marek
Re: Towards GNU11
On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote: > The consensus seems to be to go forward with this change. I will > commit the patch in 24 hours unless I hear objections. I made the change. Please report any fallout to me. Enjoy. Marek
Re: Towards GNU11
On Wed, Oct 15, 2014 at 12:08 PM, Marek Polacek wrote: > On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote: >> The consensus seems to be to go forward with this change. I will >> commit the patch in 24 hours unless I hear objections. > > I made the change. Please report any fallout to me. Most of the graphite tests don't compile with -std=c11 for me. FAIL: gcc.dg/graphite/id-1.c (test for excess errors) FAIL: gcc.dg/graphite/id-13.c (test for excess errors) FAIL: gcc.dg/graphite/id-17.c (test for excess errors) FAIL: gcc.dg/graphite/id-2.c (test for excess errors) FAIL: gcc.dg/graphite/id-23.c (test for excess errors) FAIL: gcc.dg/graphite/id-26.c (test for excess errors) FAIL: gcc.dg/graphite/id-4.c (test for excess errors) FAIL: gcc.dg/graphite/id-8.c (test for excess errors) FAIL: gcc.dg/graphite/id-pr43464-1.c (test for excess errors) FAIL: gcc.dg/graphite/id-pr43464.c (test for excess errors) FAIL: gcc.dg/graphite/id-pr45230-1.c (test for excess errors) FAIL: gcc.dg/graphite/id-pr45230.c (test for excess errors) FAIL: gcc.dg/graphite/id-pr45231.c (test for excess errors) FAIL: gcc.dg/graphite/pr37485.c (test for excess errors) FAIL: gcc.dg/graphite/pr38073.c (test for excess errors) FAIL: gcc.dg/graphite/pr38125.c (test for excess errors) FAIL: gcc.dg/graphite/pr38409.c (test for excess errors) FAIL: gcc.dg/graphite/pr38413.c (test for excess errors) FAIL: gcc.dg/graphite/pr38500.c (test for excess errors) FAIL: gcc.dg/graphite/pr38510.c (test for excess errors) FAIL: gcc.dg/graphite/pr38786.c (test for excess errors) FAIL: gcc.dg/graphite/pr39260.c (test for excess errors) FAIL: gcc.dg/graphite/pr42284.c (test for excess errors) FAIL: gcc.dg/graphite/pr42914.c (test for excess errors) FAIL: gcc.dg/graphite/pr46404-1.c (test for excess errors) FAIL: gcc.dg/graphite/pr60979.c (test for excess errors) FAIL: gcc.dg/graphite/scop-19.c (test for excess errors) Richard. > Enjoy. > > Marek
Re: Towards GNU11
On Wed, Oct 15, 2014 at 3:08 AM, Marek Polacek wrote: > On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote: >> The consensus seems to be to go forward with this change. I will >> commit the patch in 24 hours unless I hear objections. > > I made the change. Please report any fallout to me. Yes the Linux kernel fails to compile for aarch64 after this change: In file included from include/linux/mutex.h:15:0, from include/linux/kvm_host.h:12, from arch/arm64/kvm/../../../virt/kvm/kvm_main.c:21: include/linux/spinlock_types.h:82:2: error: initializer element is not constant (spinlock_t ) __SPIN_LOCK_INITIALIZER(lockname) ^ include/linux/spinlock_types.h:84:43: note: in expansion of macro ‘__SPIN_LOCK_UNLOCKED’ #define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x) ^ arch/arm64/kvm/../../../virt/kvm/kvm_main.c:75:1: note: in expansion of macro ‘DEFINE_SPINLOCK’ DEFINE_SPINLOCK(kvm_lock); ^ include/linux/spinlock_types.h:60:2: error: initializer element is not constant (raw_spinlock_t) __RAW_SPIN_LOCK_INITIALIZER(lockname) ^ include/linux/spinlock_types.h:62:51: note: in expansion of macro ‘__RAW_SPIN_LOCK_UNLOCKED’ #define DEFINE_RAW_SPINLOCK(x) raw_spinlock_t x = __RAW_SPIN_LOCK_UNLOCKED(x) ^ arch/arm64/kvm/../../../virt/kvm/kvm_main.c:76:8: note: in expansion of macro ‘DEFINE_RAW_SPINLOCK’ static DEFINE_RAW_SPINLOCK(kvm_count_lock); ^ > > Enjoy. > > Marek
Re: Towards GNU11
On Thu, Oct 16, 2014 at 3:35 PM, Andrew Pinski wrote:
> On Wed, Oct 15, 2014 at 3:08 AM, Marek Polacek wrote:
>> On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote:
>>> The consensus seems to be to go forward with this change. I will
>>> commit the patch in 24 hours unless I hear objections.
>>
>> I made the change. Please report any fallout to me.
>
> Yes the Linux kernel fails to compile for aarch64 after this change:
> In file included from include/linux/mutex.h:15:0,
> from include/linux/kvm_host.h:12,
> from arch/arm64/kvm/../../../virt/kvm/kvm_main.c:21:
> include/linux/spinlock_types.h:82:2: error: initializer element is not
> constant
> (spinlock_t ) __SPIN_LOCK_INITIALIZER(lockname)
> ^
> include/linux/spinlock_types.h:84:43: note: in expansion of macro
> ‘__SPIN_LOCK_UNLOCKED’
> #define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x)
>^
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:75:1: note: in expansion
> of macro ‘DEFINE_SPINLOCK’
> DEFINE_SPINLOCK(kvm_lock);
> ^
> include/linux/spinlock_types.h:60:2: error: initializer element is not
> constant
> (raw_spinlock_t) __RAW_SPIN_LOCK_INITIALIZER(lockname)
> ^
> include/linux/spinlock_types.h:62:51: note: in expansion of macro
> ‘__RAW_SPIN_LOCK_UNLOCKED’
> #define DEFINE_RAW_SPINLOCK(x) raw_spinlock_t x = __RAW_SPIN_LOCK_UNLOCKED(x)
>^
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:76:8: note: in expansion
> of macro ‘DEFINE_RAW_SPINLOCK’
> static DEFINE_RAW_SPINLOCK(kvm_count_lock);
> ^
Here is a short testcase which shows the behavior difference between
GNU89 and GNU11:
typedef struct {
volatile unsigned int lock;
} arch_rwlock_t;
typedef struct {
arch_rwlock_t raw_lock;
} rwlock_t;
static rwlock_t step_hook_lock = (rwlock_t) { .raw_lock = { 0 }, };
Thanks,
Andrew
>
>
>
>>
>> Enjoy.
>>
>> Marek
