draft 3.1.1 release notes (PRs fixed in 3.1.1)

[Joe Buck <Joe dot Buck at synopsys dot com>]

Here's one more revision; I'm now calling it "release notes" since others
have used that term.  Note that as I write this, GCC 3.1.1 has not yet
shipped; this describes the current state of the CVS release branch.

-----------------------------------------------------------------------

Unofficial release notes for GCC 3.1.1

GCC 3.1.1 is a bug fix release only; other than bug fixes there are no
new features that were not present in GCC 3.1.

This document lists the problem reports (PRs) from GCC's bug tracking
system (GNATS) that are known to be fixed in the 3.1.1 release.  This
list might not be complete.

To learn more about a particular PR, visit the link

	http://gcc.gnu.org/cgi-bin/gnatsweb.pl

and enter the PR number in the "View Problem Report" dialog box.  Then
click the "View" button.  It's not necessary to log in to view reports.

My sorting is slightly different from the GNATS categories.

First, internal compiler errors (ICEs).  Some processor-specific ICEs
appear in the processor-specific section, the following PRs are present on
multiple platforms.

6255: (c++) ICE with implicit typename in a template
6643: ICE in assignment to var-size array
6706: (c++) ICE generating DWARF debug for var-length array
6723: (c++) ICE with template template parameter as default
6809: ICE in gcc 3.1 if -fverbose-asm is specified
6844: ICE when -dD option is specified
6892: (c++) ICE from #include inside switch() inside template function
7070: ICE with -Wunknown-pragmas and empty #pragma
7112: (c++) ICE on code involving templates and sizeof (name mangling issue)

C errors and optimization bugs

3467: c89 violation reported with -std=c99 -pedantic (var-size array)
6517: gcc hangs on C compile with multiple "-I-"
6660: typedef'd unnamed structs/unions don't compile with gcc 3.1
6677: bug in signed char treatment
6722: global register hoisted out of loop containing a call
6780: incorrect diagnosis of token pasting
6793: varargs function inlined inappropriately
7030: incorrect DWARF debug info emitted

C++ errors:

 189: DR 259: issue with explicit template instantiation (SEE NOTE BELOW)
6381: Missing assembler label when -g is given (DWARF issue)
6611: Non-weak emission of std::__default_alloc_template, should be weak
6641: Problems with redefinition of __USE_MALLOC (SEE NOTE BELOW)
6695: regression: template friend declaration doesn't work
6716: loop and fill ram during compiling
6747: C++ rejects inline assembly, C works
6944: default copy constructor doesn't work with multi-dimensional arrays
7145: g++ -O with struct initializer and return value opt generates bad code
7224: no diagnostic for unused ambiguous inline member functions
7279: gcc 3.1 named return value related miscompilation

libstdc++ errors:

3946: auto_ptr_ref constructor allows dangerous conversion
6282: bitset<0> results in nonsense behavior
6518: ostream << operator crashes when given a null pointer
6594: strstreambuf leaks 16 bytes - gcc 3.0.x
6648: interactive cin.getline(): need to type "return" twice
6701: do_narrow on range is fubar
6795: stringbuf failure: segfault during >> after first underflow
6811: Missing 'return *this' in __enc_traits assignment operator in gcc 3.1
6886: bit vector iterator uses wrong 1 constant (affects 64-bit platforms)
7057: Operator== on hashtables doesn't appear to work correctly
7097: _GLIBCPP_HAVE_MBSTATE_T breaks non-GLIB systems
7173: _GLIBCPP_VERSION expands to an empty string in gcc 3.1

Objective-C:

6834: gcc 3.1 wrongly compiles some GNUstep code

libjava:

7292: java.lang.Character.toString(char) should be static

Platform-specific bugs:

ix86-specific:

6753: gcc 3.1 produces wrong code with -march=pentium4 -ffast-math
7010: Bug in gcc 3.1 with inline memcpy on i386 (affects Mozilla)
7245: ICE in find_reloads

sparc-specific:

6103: sparc-sun-solaris2.7 gcc 3.1 extra testsuite failures with -m64
6759: ICE when compiling 32-bit Sparc code
6788: mult inheritance "non-virtual thunk" assembly wrong for sparc64
6841: ICE for gcc 3.1 (building openssh) with -mcpu=ultrasparc -O3
6922: ICE for gcc 3.1 (building LAME) with -mcpu=ultrasparc
7012: (libstdc++) istringstream cannot read integers on Solaris 2.5.1 and 2.6

PowerPC specific:

6615: PPC: insn does not satisfy its constraints
7147: if-convert problem (regression: affects mozilla compilation)
7282: (powerpc64-linux) unrecognizable insn

IBM s390x specific:

6963: Linux kernel for s390x miscompiled

CRIS specific (CRIS is an embedded processor):

6838: cris-elf ICE (gcc 3.1)
6997: cris: compare result incorrect, sleu pattern in cris.md bad
7042: cris-elf miscompiles line_hints in ghostscript
7177: cris-axis-elf: ICE at -O2, unrecognized insn

PRs reported against the release CVS branch, but not present in any GCC
release (including 3.1.1):

6750 (libstdc++) ofstream incorrectly sets failbit (severe regression)
6822 (i586) ICE in extract_insn, at recog.c:2132

Additional notes on some PRs:

PR 189:
      There was an issue in the C++ language standard with respect to explicit
      and implicit instantiation of the same template (defect report #259).
      gcc 3.1.1 implements the resolution proposed to the ISO C++
      committee by Matt Austern, which will probably become official (see
      http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#259 )

PR 6641:
      In gcc 3.x, it is not supported to define __USE_MALLOC (to suppress
      the use of allocators in the standard template library classes) unless
      libstdc++ itself is rebuilt with __USE_MALLOC defined.  gcc 3.1.1
      will detect attempts to link together inconsistent code and issue
      a diagnostic (in earlier 3.x versions a link failure or even a
      crash might result, from using a different allocation method for
      allocation and freeing).

      Note that in gcc 2.x it was possible to redefine __USE_MALLOC
      without rebuilding libstdc++, since no code in the library itself
      (as opposed to header files) depended on this symbol, although even
      then it was error-prone (all program units that instantiated a given
      template needed to agree on the __USE_MALLOC definition), and if
      users were not careful similar crashes could result.

      There is work in progress to provide a cleaner solution for users
      who need finer-tuned control over the default allocation strategy,
      though we can't say when it will be available.