Towards GNU11

[Marek Polacek]

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 <***@redhat.com>

* 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]

Post by Marek Polacek
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.
- 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.

Post by Marek Polacek
Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
* 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
+GNU dialect of ISO C11. This is the default for C code.
@item c++98
@itemx c++03
Marek

[Marek Polacek]

Post by Richard Biener
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!

Post by Richard Biener
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

[Matthias Klose]

Post by Richard Biener
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

[Jason Merrill]

Post by Matthias Klose
What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still
a target for GCC 5?

Yes.

Jason

[Jeff Law]

Post by Marek Polacek
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.
- 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.
* 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

[Marek Polacek]

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

[Joseph S. Myers]

Post by Marek Polacek

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