Re: problems with iso restrict

Re: problems with iso restrict

[Jeffrey A Law]

  In message <r2ogpjrb79.fsf@happy.cygnus.com>you write:
  > Mark Mitchell <mark@markmitchell.com> writes:
  > 
  > > Right.  I have no idea how Ulrich and crew have set up the various
  > > -std= options and what the defaults are.  `restrict' should not be
  > > reserved if flag_isoc9x is not set:
  > 
  > The point is to decide what GNU C is.  Does GNU C include all
  > extensions of ISO C 89 and ISO C 9x?  I think so and the patch
  > reflects this.
*Right now*, I would think GNU C should be backwards compatible with existing
GNU C implementations.  If that means c9x should not be the default right now
because of namespace pollution with "restrict", then so be it.

While I agree that we want to move towards c9x, I'd like to get more input from
developers & users about when to move.

I also think that enabling c9x by default when our c9x support is not even 
conforming to the existing standard was a serious mistake.

So, I think for the *short term* we should revert to the default behavior until
we get some more input from the users & developers about when to make the
cutover.


  > If you now want to have GNU C not including all ISO C 9x extensions we
  > will have to exclude the definition.  This is IMO a big mistake since
  > now GNU C is inferior to ISO C 9x.
It should be an option.  And until we have more feedback, I think the default
should be the way GNU C was working before the c9x stuff.

Just because you think GNU C is inferior does not mean everyone does.  Nor does
it mean everyone is ready to convert their code at this time.  There may be
some folks that will never convert their code.  There is no reason to punish
those users.


  > If this should not happen there will be a time where we have to bite
  > the bullet and introduce `restrict'.  The committee made the decision
  > to violate their namespace rules by defining a symbol in the user
  > namespace but so be it.  All code sooner or later has to be adapted
  > for this.  Why not do it sooner and prevent people from now on from
  > writing code which will be invalid under c9x rules?
Not all code must be adapted.  Folks should have the option to get the old
GNU behavior.

So, does the compiler actually default to c9x right now?  I'm making that
assumption, but I do not know if it is true.

jeff

Re: problems with iso restrict

[Richard Henderson]

On Fri, Dec 04, 1998 at 12:07:52PM -0700, Jeffrey A Law wrote:
> *Right now*, I would think GNU C should be backwards compatible with existing
> GNU C implementations.  If that means c9x should not be the default right now
> because of namespace pollution with "restrict", then so be it.

How about the following patch.  It removes -std=gnu in favour of
-std=gnu89 and -std=gnu9x.  This obviates the suggestion made 
earlier for such nastiness as -std=c9x -ansi.


r~



Index: c-decl.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/c-decl.c,v
retrieving revision 1.52
diff -u -p -r1.52 c-decl.c
--- c-decl.c	1998/12/01 21:04:56	1.52
+++ c-decl.c	1998/12/04 19:47:44
@@ -470,7 +470,7 @@ int flag_traditional;
 
 /* Nonzero means use the ISO C9x dialect of C.  */
 
-int flag_isoc9x = 1;
+int flag_isoc9x = 0;
 
 /* Nonzero means that we have builtin functions, and main is an int */
 
@@ -657,11 +657,12 @@ c_decode_option (argc, argv)
       /* Select the appropriate language standard.  We currently
 	 recognize:
 	 -std=iso9899:1990	same as -ansi
-	 -std=gnu		default
 	 -std=iso9899:199409	ISO C as modified in amend. 1
 	 -std=iso9899:199x	ISO C 9x
 	 -std=c89		same as -std=iso9899:1990
 	 -std=c9x		same as -std=iso9899:199x
+	 -std=gnu89		default, iso9899:1990 + gnu extensions
+	 -std=gnu9x		iso9899:199x + gnu extensions
       */
       const char *argstart = &p[5];
 
@@ -689,7 +690,15 @@ c_decode_option (argc, argv)
 	  flag_no_nonansi_builtin = 1;
 	  flag_isoc9x = 1;
 	}
-      else if (!strcmp (argstart, "gnu"))
+      else if (!strcmp (argstart, "gnu89"))
+	{
+	  flag_traditional = 0;
+	  flag_writable_strings = 0;
+	  flag_no_asm = 0;
+	  flag_no_nonansi_builtin = 0;
+	  flag_isoc9x = 0;
+	}
+      else if (!strcmp (argstart, "gnu9x"))
 	{
 	  flag_traditional = 0;
 	  flag_writable_strings = 0;
Index: cccp.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cccp.c,v
retrieving revision 1.45
diff -u -p -r1.45 cccp.c
--- cccp.c	1998/12/01 21:05:04	1.45
+++ cccp.c	1998/12/04 19:48:11
@@ -1172,7 +1172,7 @@ print_help ()
   printf ("  -lang-asm                 Assume that the input sources are in assembler\n");
   printf ("  -lang-chill               Assume that the input sources are in Chill\n");
   printf ("  -std=<std name>           Specify the conformance standard; one of:\n");
-  printf ("                            gnu, c89, c9x, iso9899:1990,\n");
+  printf ("                            gnu89, gnu9x, c89, c9x, iso9899:1990,\n");
   printf ("                            iso9899:199409, iso9899:199x\n");
   printf ("  -+                        Allow parsing of C++ style features\n");
   printf ("  -w                        Inhibit warning messages\n");
@@ -1494,11 +1494,12 @@ main (argc, argv)
       case 's':
 	if (!strcmp (argv[i], "-std=iso9899:1990")
 	    || !strcmp (argv[i], "-std=iso9899:199409")
-	    || !strcmp (argv[i], "-std=c89"))
+	    || !strcmp (argv[i], "-std=c89")
+	    || !strcmp (argv[i], "-std=gnu89"))
 	  cplusplus = 0, cplusplus_comments = 0, c89 = 1, c9x = 0, objc = 0;
         else if (!strcmp (argv[i], "-std=iso9899:199x")
 		 || !strcmp (argv[i], "-std=c9x")
-		 || !strcmp (argv[i], "-std=gnu"))
+		 || !strcmp (argv[i], "-std=gnu9x"))
 	  cplusplus = 0, cplusplus_comments = 1, c89 = 0, c9x = 1, objc = 0;
 	break;
 
Index: gcc.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/gcc.c,v
retrieving revision 1.74
diff -u -p -r1.74 gcc.c
--- gcc.c	1998/12/01 21:05:08	1.74
+++ gcc.c	1998/12/04 19:48:22
@@ -586,8 +586,8 @@ static struct compiler default_compilers
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
-	%{ansi|std=*:%{!std=gnu:-trigraphs -D__STRICT_ANSI__}}\
-	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu:%p}} %P} %{trigraphs}\
+	%{ansi|std=*:%{!std=gnu*:-trigraphs -D__STRICT_ANSI__}}\
+	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs}\
         %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}}\
         %{traditional} %{ftraditional:-traditional}\
         %{traditional-cpp:-traditional}\
@@ -599,8 +599,8 @@ static struct compiler default_compilers
                   %{!Q:-quiet} -dumpbase %b.c %{d*} %{m*} %{a*}\
                   %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
                   -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
-		  %{ansi|std=*:%{!std=gnu:-trigraphs -D__STRICT_ANSI__}}\
-		  %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu:%p}} %P} %{trigraphs}\
+		  %{ansi|std=*:%{!std=gnu*:-trigraphs -D__STRICT_ANSI__}}\
+		  %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs}\
                   %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}}\
                   %{H} %C %{D*} %{U*} %{i*} %Z\
                   %{ftraditional:-traditional}\
@@ -621,8 +621,8 @@ static struct compiler default_compilers
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
-	%{ansi|std=*:%{!std=gnu:-trigraphs -D__STRICT_ANSI__}}\
-	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu:%p}} %P} %{trigraphs}\
+	%{ansi|std=*:%{!std=gnu*:-trigraphs -D__STRICT_ANSI__}}\
+	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs}\
         %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}}\
         %{traditional} %{ftraditional:-traditional}\
         %{traditional-cpp:-traditional}\
@@ -648,8 +648,8 @@ static struct compiler default_compilers
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
-	%{ansi|std=*:%{!std=gnu:-trigraphs -D__STRICT_ANSI__}}\
-	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu:%p}} %P} %{trigraphs}\
+	%{ansi|std=*:%{!std=gnu*:-trigraphs -D__STRICT_ANSI__}}\
+	%{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs}\
         %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}}\
         %{traditional} %{ftraditional:-traditional}\
         %{traditional-cpp:-traditional}\
@@ -664,8 +664,8 @@ static struct compiler default_compilers
 	%{C:%{!E:%eGNU C does not support -C without using -E}}\
 	 %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
         -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
-	%{std=*:%{!std=gnu:-trigraphs -D__STRICT_ANSI__}}\
-	%{!undef:%{!std=*:%p}%{std=gnu:%p} %P} %{trigraphs}\
+	%{std=*:%{!std=gnu*:-trigraphs -D__STRICT_ANSI__}}\
+	%{!undef:%{!std=*:%p}%{std=gnu*:%p} %P} %{trigraphs}\
         %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}}\
         %{traditional} %{ftraditional:-traditional}\
         %{traditional-cpp:-traditional}\

Re: problems with iso restrict

[Jeffrey A Law]

  In message < 19981204115040.B12670@dot.cygnus.com >you write:
  > On Fri, Dec 04, 1998 at 12:07:52PM -0700, Jeffrey A Law wrote:
  > > *Right now*, I would think GNU C should be backwards compatible with exis
  > ting
  > > GNU C implementations.  If that means c9x should not be the default right
  >  now
  > > because of namespace pollution with "restrict", then so be it.
  > 
  > How about the following patch.  It removes -std=gnu in favour of
  > -std=gnu89 and -std=gnu9x.  This obviates the suggestion made 
  > earlier for such nastiness as -std=c9x -ansi.
The patch seems reasonable to me.

The next thing to do is make an educated decision about when to change the
default to be c9x.  I think this decision mostly hinges on whether or not the
next major release should have c9x enabled by default or not.  (Yes, this
means I'm leaning towards egcs-1.2 branching from the mainline sources instead
of a continuation of the egcs-1.1 branch).

My gut tells me we announce support for c9x in the next major release (1.2),
but do not enable it by default until one major release after that (1.3).

This gives folks a chance to transition their code to be c9x complaint.  Of
course to do that they need info on c9x's features (web page anyone?) and
info on how closely we follow the standard.  I want this information regardless
of when we decide to make c9x the default so that I can put it in the egcs news
section on the web page.

jeff

Re: problems with iso restrict

[Ulrich Drepper]

Jeffrey A Law <law@hurl.cygnus.com> writes:

>  Of > course to do that they need info on c9x's features (web page
>  anyone?) and > info on how closely we follow the standard.  I want
>  this information regardless > of when we decide to make c9x the
>  default so that I can put it in the egcs news > section on the web
>  page.

Somebody posted on comp.std.c some time back a list of the changes
which we might be able to find.  But I might also write a section for
the gcc manual explaining the extensions.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: problems with iso restrict

[Andi Kleen]

In muc.lists.egcs.misc, you wrote:
>This gives folks a chance to transition their code to be c9x complaint.  Of
>course to do that they need info on c9x's features (web page anyone?) and
>info on how closely we follow the standard.  I want this information regardless
>of when we decide to make c9x the default so that I can put it in the egcs news
>section on the web page.

Important C9x features still missing in egcs:

- Free statement/declaration mixing inside blocks (my favourite) and support
for having a declaration in for 
[for(int i = 0; i < 10; i++) { /* i in scope */ }]. The hard part in
implementing it is to make sure that the bison parser will still give
sensible errors for common situations. 
I think that feature should be definitely in before egcs is announcing C9x
support.

Transitions needed:

- Moving from gcc style complex support to C9x complex support. Lots of work.
Is there a relevant user base of the old gcc-style complex support?
- Changing the gcc 'inline' keyword semantics to c9x semantics (inline in C9x
implies static). This will hurt.

Very nice to have would be:
- Support for #pragma FP_CONTRACT

-Andi

Re: problems with iso restrict

[Joe Buck]

> Important C9x features still missing in egcs:
> 
> - Free statement/declaration mixing inside blocks (my favourite) and support
> for having a declaration in for 
> [for(int i = 0; i < 10; i++) { /* i in scope */ }].

> The hard part in
> implementing it is to make sure that the bison parser will still give
> sensible errors for common situations. 

But these are both standard C++ features, so the problem has already
been solved in the C++ bison parser.

> - Moving from gcc style complex support to C9x complex support. Lots of work.
> Is there a relevant user base of the old gcc-style complex support?

That's probably the biggest task.  C9x complex is nothing like C++ complex
so there is no help there.

> - Changing the gcc 'inline' keyword semantics to c9x semantics (inline in C9x
> implies static). This will hurt.

Again that is a standard C++ feature.

> Very nice to have would be:
> - Support for #pragma FP_CONTRACT
> 
> -Andi
> 

Re: problems with iso restrict

[Martin von Loewis]

> My gut tells me we announce support for c9x in the next major release (1.2),
> but do not enable it by default until one major release after that (1.3).

Well, I'd think we should default to c9x only when x is definite. Of
course, x must be 9 :-)

ADVHappy new yearANCE,
Martin

Re: problems with iso restrict

[Alexandre Oliva]

On Dec  8, 1998, Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> My gut tells me we announce support for c9x in the next major release (1.2),
>> but do not enable it by default until one major release after that (1.3).

> Well, I'd think we should default to c9x only when x is definite. Of
> course, x must be 9 :-)

Unless the standard is delayed and they decide that the second digit
is actually an hex digit, so that they can say c9A :-)

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil