gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK.

	* gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK.
	* README.TRAD, TESTS.FLUNK: Remove.

From-SVN: r36846

gcc/ChangeLog

 2000-10-12  Joseph S. Myers  <jsm28@cam.ac.uk>
 
+	* gcc.texi: Merge in contents of README.TRAD and TESTS.FLUNK.
+	* README.TRAD, TESTS.FLUNK: Remove.
+
+2000-10-12  Joseph S. Myers  <jsm28@cam.ac.uk>
+
 	* c-common.c (decl_attributes): Don't allow strftime formats with
 	first_arg_num nonzero.
 	(check_format_info): Set wanted_type and wanted_type_name to zero

gcc/README.TRAD

-This is a partial list of how `gcc -traditional' disagrees with
-traditional C compilers (perhaps only some of them).  Most of these
-differences are not bugs.
-
----------------------------------------------------------------------------
-K&R-1 (2.4.3) says:
-
-	"If the character following a backslash is not one of those
-	specified {in the table above}, the backslash is ignored."
-
-Up until recently, `gcc -traditional' complained about \x \a and \v
-appearing in a character or string literal.  I believe however that
-this non-feature has been eliminated (recently).
-
----------------------------------------------------------------------------
-When in -traditional mode, gcc allows the following erroneous pair of
-declarations to appear together in a given scope:
-
-	typedef int foo;
-	typedef foo foo;
-
----------------------------------------------------------------------------
-K&R-1 (8.5) says:
-
-	"No field may be wider than a word."
-
-Gcc however allows:
-
-	struct S { int i:33; };
-
----------------------------------------------------------------------------
-In K&R-1 there is no restriction against comments crossing include file
-boundaries.  Gcc however doesn't allow this, even when in -traditional mode.
-
----------------------------------------------------------------------------
-Regarding the length of identifiers, K&R-1 (2.2) says:
-
-	"No more than the first eight characters are significant,
-	although more may be used."
-
-Gcc treats all characters of identifiers as significant, even when in
--traditional mode.
-
----------------------------------------------------------------------------
-K&R-1 (2.2) says:
-
-	"An identifier is a sequence of letters and digits; the first
-	character must be a letter.  The underscore _ counts as a letter."
-
-Gcc also allows dollar signs in identifiers.  (This may also be an issue
-for the -pedantic option.)
-
----------------------------------------------------------------------------
-
-

gcc/TESTS.FLUNK

-This is a collection of things that test suites have
-said were "wrong" with GCC--but that I don't agree with.
-
-First, test suites sometimes test for compatibility with
-traditional C.  GCC with -traditional is not completely
-compatible with traditional C, and in some ways I think it
-should not be.
-
-* K&R C allowed \x to appear in a string literal (or character
-literal?)  even in cases where it is *not* followed by a sequence of
-hex digits.  I'm not convinced this is desirable.
-
-* K&R compilers allow comments to cross over an inclusion boundary (i.e.
-started in an include file and ended in the including file).
-I think this would be quite ugly and can't imagine it could
-be needed.
-
-Sometimes tests disagree with GCC's interpretation of the ANSI standard.
-
-* One test claims that this function should return 1.
-
-    enum {A, B} foo;
-
-    func (enum {B, A} arg)
-    {
-      return B;
-    }
-
-I think it should return 0, because the definition of B that
-applies is the one in func.
-
-* Some tests report failure when the compiler does not produce
-an error message for a certain program.
-
-ANSI C requires a "diagnostic" message for certain kinds of invalid
-programs, but a warning counts as a diagnostic.  If GCC produces
-a warning but not an error, that is correct ANSI support.
-When test suites call this "failure", the tests are broken.
-

gcc/gcc.texi

@@ -1312,6 +1312,11 @@ ANSI C does not permit such a construct.  It would make sense to support
 it when @samp{-traditional} is used, but it is too much work to
 implement.
 
+@item
+K&R compilers allow comments to cross over an inclusion boundary (i.e.
+started in an include file and ended in the including file).  I think
+this would be quite ugly and can't imagine it could be needed.
+
 @cindex external declaration scope
 @cindex scope of external declarations
 @cindex declaration scope
@@ -1345,6 +1350,23 @@ flag cannot alter it.
 PCC allows typedef names to be used as function parameters.  The
 difficulty described immediately above applies here too.
 
+@item
+When in @samp{-traditional} mode, GCC allows the following erroneous
+pair of declarations to appear together in a given scope:
+
+@example
+typedef int foo;
+typedef foo foo;
+@end example
+
+@item
+GCC treats all characters of identifiers as significant, even when in
+@samp{-traditional} mode.  According to K&R-1 (2.2), ``No more than the
+first eight characters are significant, although more may be used.''.
+Also according to K&R-1 (2.2), ``An identifier is a sequence of letters
+and digits; the first character must be a letter.  The underscore _
+counts as a letter.'', but GCC also allows dollar signs in identifiers.
+
 @cindex whitespace
 @item
 PCC allows whitespace in the middle of compound assignment operators
@@ -1379,8 +1401,10 @@ return.  But in systems with ANSI C headers, @code{time} is declared to
 return @code{time_t}, and if that is not the same as @code{long}, then
 @samp{long time ();} is erroneous.
 
-The solution is to change your program to use @code{time_t} as the return
-type of @code{time}.
+The solution is to change your program to use appropriate system headers
+(@code{<time.h>} on systems with ISO C headers) and not to declare
+@code{time} if the system header files declare it, or failing that to
+use @code{time_t} as the return type of @code{time}.
 
 @cindex @code{float} as function value type
 @item
@@ -2079,6 +2103,20 @@ Strictly speaking, there is no prohibition in the ANSI C standard
 against allowing structures with volatile fields in registers, but
 it does not seem to make any sense and is probably not what you wanted
 to do.  So the compiler will give an error message in this case.
+
+@item
+Making certain warnings into errors by default.
+
+Some ISO C testsuites report failure when the compiler does not produce
+an error message for a certain program.
+
+ISO C requires a ``diagnostic'' message for certain kinds of invalid
+programs, but a warning is defined by GCC to count as a diagnostic.  If
+GCC produces a warning but not an error, that is correct ISO C support.
+If test suites call this ``failure'', they should be run with the GCC
+option @samp{-pedantic-errors}, which will turn these warnings into
+errors.
+
 @end itemize
 
 @node Warnings and Errors