public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc 3.2.1 draft release notes, 3rd draft
@ 2002-10-14 17:38 Joe Buck
  2002-10-15  1:27 ` Mark Mitchell
  2002-10-15  9:02 ` Alexandre Oliva
  0 siblings, 2 replies; 14+ messages in thread
From: Joe Buck @ 2002-10-14 17:38 UTC (permalink / raw)
  To: gcc

Here's a third draft for GCC 3.2.1 release notes.  Please let me know
about anything else that should be mentioned.

A number of additional bugs have been fixed, and bugfixing is still in
progress, so no doubt more will be added to this list.  I've added a note
on -Wabi and the removal of "Named Types", which hasn't had much
publicity.

Can we always tell people to turn

typedef T = expression;

into

typedef typeof(expression) T;

?

--------------------------------------------------------------------
Informal release notes for GCC 3.2.1

3.2.1 adds a new warning, -Wabi.  This option warns when GNU C++ generates
code that is known not to be binary-compatible with the vendor-neutral
ia32/ia64 ABI.  Please consult the GCC manual, included in the
distribution, for details.

This release also removes an old GCC extension, "naming types", and the
documentation now directs users to use a different GCC extension,
"typeof", instead.  The feature had evidently been broken for a while.

Otherwise, 3.2.1 is a bug fix release only; other than bug fixes there are
no new features that were not present in GCC 3.2.

This document lists the problem reports (PRs) from GCC's bug tracking
system (GNATS) that are known to be fixed in the 3.2.1 release. This
list might not be complete (that is, it is possible that some bug fixes
have been missed).

One bug from Debian's bug tracking system is listed as well, since there
is no corresponding PR for it.  (maybe in the future we should make sure
that there's a PR for such things, once they are determined not to be
Debian-specific?).

In addition, the previous fix for PR 7445 (poor performance of
std::locale::classic() in multi-threaded applications) was reverted
("unfixed"), because the "fix" was not thread-safe.

Thanks to Daniel Jacobowitz for doing an early draft of this list.

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, and I changed
some of the titles to make them more clear.

First, internal compiler errors (ICEs).  These are multi-platform; some
processor-specific ICEs are listed below.

5661    (c++) ICE instantiating template on array of unknown size (bad code)
7150	preprocessor: gcc -dM -E gives an ICE
7160	gcc 3.1 gives an ICE when optimizing valid code
7353	ICE from use of "Naming Types" extension, see above
7411	ICE in instantiate_virtual_regs_1, at function.c:3974
7526	preprocessor core dump when _Pragma implies #pragma dependency
7721	(c++) ICE on simple (but incorrect) template (7803 is a duplicate)
7754	(c++) ICE on union with template parameter
8055	preprocessor dies with SIG11 when building FreeBSD kernel

C++ bugs

5607	No pointer adjustment in covariant return types
6803	Default copy constructor bug in GCC 3.1
7176	g++ confused by friend and static member with same name
7188	Segfault with template class and recursive (incorrect) initalizer list
7461	ctype<char>::classic_table() returns offset array on Cygwin
7811	default locale not taken from environment
8071	basic_ostream::operator<<(streambuf*) loops forever if
	streambuf::underflow() leaves gptr() NULL (dups: 8127, 6745)
8127	cout << cin.rdbuf() infinite loop
8096    deque::at() throws std::range_error instead of std::out_of_range


C and optimizer bugs

6627    -fno-align-functions doesn't seem to disable function alignment
7102	unsigned char divisision results in floating exception
7120	Run once loop should *always* be unrolled (pessimization)
7515	invalid inlining of global function with -O3
7814	incorrect scheduling for glibc-2.2.92 stpcpy test


Preprocessor bugs

7357	-M option omits system headers files (making it the same as -MM)
7358	Changes to Sun's make Dependencies
7602	C++ header files found in CPLUS_INCLUDE_PATH treated as C headers
Debian BTS 157416: _Pragma within macro is improperly expanded

x86-specific (Intel/AMD):

6845,7034,7124,7174: ICE's with -march=pentium3/pentium2/athlon
(these are all the same underlying bug, in MMX register use)
7134,7375,7390    ICE with -march=athlon (maybe same as above?)
7242    gcc -mcpu=pentium[23] doesn't define __tune_pentiumpro__ macro
7723	ICE - Pentium3 sse - gcc 3.2
7951	ICE on -march=pentium4 -O2 -mfpmath=sse

PowerPC-specific:
5967	gcc bug when profiling nested functions on powerpc
6984	wrong code generated with -O2, -O3, -Os for do-while loop on PowerPC
7114	PowerPC: ICE building strcoll.op from glibc-2.2.5
7130	miscompiled code for gcc-3.1 in powerpc linux with -funroll-all-loops
7380	ICE in extract_insn, at recog.c:2148

Sparc-specific:
7151	ICE when compiling for UltraSPARC
7335	Sparc: ICE in verify_wide_reg (flow.c:557) with long double and -O1
7842	[REGRESSION] sparc code gen bug

ARM-specific:
7967	optimization produces wrong code (ARM)

Alpha-specific:
7374	__builtin_fabsl broken on alpha

Documentation:
5610	Fix documentation about invoking SSE instructions (-mfpmath=sse)
7484	List -Wmissing-declarations as C-only option
7531	-mcmodel not documented for x86-64
8120	Update documentation of bad use of ##



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-14 17:38 gcc 3.2.1 draft release notes, 3rd draft Joe Buck
@ 2002-10-15  1:27 ` Mark Mitchell
  2002-10-15 10:10   ` Joe Buck
  2002-10-15  9:02 ` Alexandre Oliva
  1 sibling, 1 reply; 14+ messages in thread
From: Mark Mitchell @ 2002-10-15  1:27 UTC (permalink / raw)
  To: Joe Buck, gcc



--On Monday, October 14, 2002 03:40:54 PM -0700 Joe Buck 
<jbuck@synopsys.com> wrote:

> Here's a third draft for GCC 3.2.1 release notes.  Please let me know
> about anything else that should be mentioned.

I can't say how much I appreciate that you do this.

> Can we always tell people to turn
>
> typedef T = expression;
>
> into
>
> typedef typeof(expression) T;
>
> ?

Yes; those two forms should be equivalent, as far as I know.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-14 17:38 gcc 3.2.1 draft release notes, 3rd draft Joe Buck
  2002-10-15  1:27 ` Mark Mitchell
@ 2002-10-15  9:02 ` Alexandre Oliva
  2002-10-15  9:18   ` Gabriel Dos Reis
  1 sibling, 1 reply; 14+ messages in thread
From: Alexandre Oliva @ 2002-10-15  9:02 UTC (permalink / raw)
  To: Joe Buck; +Cc: gcc

On Oct 14, 2002, Joe Buck <jbuck@synopsys.com> wrote:

> typedef typeof(expression) T;

> ?

How about suggesting __typeof, so as to hint that this is not Standard
C++?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15  9:02 ` Alexandre Oliva
@ 2002-10-15  9:18   ` Gabriel Dos Reis
  0 siblings, 0 replies; 14+ messages in thread
From: Gabriel Dos Reis @ 2002-10-15  9:18 UTC (permalink / raw)
  To: Alexandre Oliva; +Cc: Joe Buck, gcc

Alexandre Oliva <aoliva@redhat.com> writes:

| On Oct 14, 2002, Joe Buck <jbuck@synopsys.com> wrote:
| 
| > typedef typeof(expression) T;
| 
| > ?
| 
| How about suggesting __typeof, so as to hint that this is not Standard
| C++?

I vote for it -- not just it isn' Standard C++, but it isn't Standard
C neither.

-- Gaby

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15  1:27 ` Mark Mitchell
@ 2002-10-15 10:10   ` Joe Buck
  2002-10-15 11:33     ` Mark Mitchell
  0 siblings, 1 reply; 14+ messages in thread
From: Joe Buck @ 2002-10-15 10:10 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Joe Buck, gcc

I wrote:

> > Can we always tell people to turn
> >
> > typedef T = expression;
> >
> > into
> >
> > typedef typeof(expression) T;
> >
> > ?
> 
> Yes; those two forms should be equivalent, as far as I know.

Then how about adding a rule something like the following to the bison
grammar (yes, I know these are the wrong terminal names, but the idea
should be clear):

       TYPEDEF ID '=' error ';'
	       { error("Please use __typeof() instead");}

However, I don't understand why the extension was removed.  If its
presence makes it harder to parse valid C/C++ the removal might be
justified.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15 10:10   ` Joe Buck
@ 2002-10-15 11:33     ` Mark Mitchell
  2002-10-15 19:11       ` Zack Weinberg
  0 siblings, 1 reply; 14+ messages in thread
From: Mark Mitchell @ 2002-10-15 11:33 UTC (permalink / raw)
  To: Joe Buck; +Cc: Joe Buck, gcc

> Then how about adding a rule something like the following to the bison
> grammar (yes, I know these are the wrong terminal names, but the idea
> should be clear):
>
>        TYPEDEF ID '=' error ';'
> 	       { error("Please use __typeof() instead");}

Along these lines, one could perhaps even do the transformation at that
point.

  TYPEDEF ID = expression ;

    { /* Do whatever you do for the typeof case. */ }


> However, I don't understand why the extension was removed.  If its
> presence makes it harder to parse valid C/C++ the removal might be
> justified.

The extension was removed because it's been broken forever and nobody
complained.  It thus seemed an opportune time to get rid of a language
extension -- they all create problems in one way or another -- and
this one was both apparently unused and had as an equivalent form.

If people think that's a bad decision, we can go back and try to do
the above transformation.  My sentiment is that -- given that there's
considerable evidence that nobody uses this extension -- our time is
best spent elsewhere.

On the other hand, as the approver of the patch, I'm responsible; I'll
attempt the transformation patch if people want that.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15 11:33     ` Mark Mitchell
@ 2002-10-15 19:11       ` Zack Weinberg
  2002-10-15 21:19         ` Joe Buck
  0 siblings, 1 reply; 14+ messages in thread
From: Zack Weinberg @ 2002-10-15 19:11 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Joe Buck, gcc

On Tue, Oct 15, 2002 at 10:08:46AM -0700, Mark Mitchell wrote:
> >Then how about adding a rule something like the following to the bison
> >grammar (yes, I know these are the wrong terminal names, but the idea
> >should be clear):
> >
> >       TYPEDEF ID '=' error ';'
> >	       { error("Please use __typeof() instead");}
> 
> Along these lines, one could perhaps even do the transformation at that
> point.
> 
>  TYPEDEF ID = expression ;
> 
>    { /* Do whatever you do for the typeof case. */ }

It's worth pointing out that the grammar does not distinguish between
typedef declarations and other declarations.  It's all handled by

datadef: declspecs declarator '=' init ';'

(simplified for clarity) The present error message comes from the
semantics layer, c-decl.c:start_decl():

  if (initialized)
    /* Is it valid for this decl to have an initializer at all?
       If not, set INITIALIZED to zero, which will indirectly
       tell `finish_decl' to ignore the initializer once it is parsed.  */
    switch (TREE_CODE (decl))
      {
      case TYPE_DECL:
        error ("typedef `%s' is initialized",
               IDENTIFIER_POINTER (DECL_NAME (decl)));
        initialized = 0;
        break;

It would be easy to insert in here

  advice ("Please use __typeof() instead");

("advice" is a diagnostic category I propose for helpful advice, such
as this, or the "Each undeclared identifier is reported only once"
message, which can be shut up with -fno-advice; right now, imagine
that it reads "error")

"Trying to do the above transformation" boils down to my original
patch that fixed the bug in the extension.

zw

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15 19:11       ` Zack Weinberg
@ 2002-10-15 21:19         ` Joe Buck
  2002-10-18  4:48           ` Zack Weinberg
  0 siblings, 1 reply; 14+ messages in thread
From: Joe Buck @ 2002-10-15 21:19 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: Mark Mitchell, Joe Buck, gcc

Zack writes:

> It would be easy to insert in here
> 
>   advice ("Please use __typeof() instead");

OK with me, I wanted to do something to minimize re-reporting of this
issue.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-15 21:19         ` Joe Buck
@ 2002-10-18  4:48           ` Zack Weinberg
  2002-10-18  5:17             ` Mark Mitchell
  2002-10-18  7:42             ` John Marshall
  0 siblings, 2 replies; 14+ messages in thread
From: Zack Weinberg @ 2002-10-18  4:48 UTC (permalink / raw)
  To: Joe Buck; +Cc: Mark Mitchell, Joe Buck, gcc

On Tue, Oct 15, 2002 at 06:39:37PM -0700, Joe Buck wrote:
> Zack writes:
> 
> > It would be easy to insert in here
> > 
> >   advice ("Please use __typeof() instead");
> 
> OK with me, I wanted to do something to minimize re-reporting of this
> issue.

For now, how's this patch look?

zw

	* c-decl.c, cp/decl.c (start_decl):  Point users of old
	"initialized typedef" extension at __typeof.

===================================================================
Index: c-decl.c
--- c-decl.c	9 Oct 2002 21:27:35 -0000	1.351
+++ c-decl.c	18 Oct 2002 03:12:07 -0000
@@ -2821,7 +2821,7 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	error ("typedef `%s' is initialized",
+	error ("typedef `%s' is initialized (use __typeof instead)",
 	       IDENTIFIER_POINTER (DECL_NAME (decl)));
 	initialized = 0;
 	break;
===================================================================
Index: cp/decl.c
--- cp/decl.c	15 Oct 2002 23:59:19 -0000	1.950
+++ cp/decl.c	18 Oct 2002 03:12:11 -0000
@@ -7292,7 +7292,7 @@ start_decl (declarator, declspecs, initi
     switch (TREE_CODE (decl))
       {
       case TYPE_DECL:
-	error ("typedef `%D' is initialized", decl);
+	error ("typedef `%D' is initialized (use __typeof instead)", decl);
 	initialized = 0;
 	break;
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-18  4:48           ` Zack Weinberg
@ 2002-10-18  5:17             ` Mark Mitchell
  2002-10-18  7:42             ` John Marshall
  1 sibling, 0 replies; 14+ messages in thread
From: Mark Mitchell @ 2002-10-18  5:17 UTC (permalink / raw)
  To: Zack Weinberg, Joe Buck; +Cc: Joe Buck, gcc



--On Thursday, October 17, 2002 08:13:14 PM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Tue, Oct 15, 2002 at 06:39:37PM -0700, Joe Buck wrote:
>> Zack writes:
>>
	* c-decl.c, cp/decl.c (start_decl):  Point users of old
	"initialized typedef" extension at __typeof.

Do it.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-18  4:48           ` Zack Weinberg
  2002-10-18  5:17             ` Mark Mitchell
@ 2002-10-18  7:42             ` John Marshall
  2002-10-22 17:20               ` Zack Weinberg
  1 sibling, 1 reply; 14+ messages in thread
From: John Marshall @ 2002-10-18  7:42 UTC (permalink / raw)
  To: Zack Weinberg; +Cc: Joe Buck, Mark Mitchell, Joe Buck, gcc

On Thu, Oct 17, 2002 at 08:13:14PM -0700, Zack Weinberg wrote:
> 	* c-decl.c, cp/decl.c (start_decl):  Point users of old
> 	"initialized typedef" extension at __typeof.

The manual (as in the 3.2 release) talks only about typeof and
__typeof__, although (to my surprise) __typeof works as well.

It might be worth talking about __foo as well as __foo__ or more likely
just having your message point to __typeof__ instead, to avoid more
postings from other surprised people :-).

    John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
  2002-10-18  7:42             ` John Marshall
@ 2002-10-22 17:20               ` Zack Weinberg
  0 siblings, 0 replies; 14+ messages in thread
From: Zack Weinberg @ 2002-10-22 17:20 UTC (permalink / raw)
  To: John Marshall; +Cc: Joe Buck, Mark Mitchell, Joe Buck, gcc

On Fri, Oct 18, 2002 at 01:43:49PM +0200, John Marshall wrote:
> On Thu, Oct 17, 2002 at 08:13:14PM -0700, Zack Weinberg wrote:
> > 	* c-decl.c, cp/decl.c (start_decl):  Point users of old
> > 	"initialized typedef" extension at __typeof.
> 
> The manual (as in the 3.2 release) talks only about typeof and
> __typeof__, although (to my surprise) __typeof works as well.
> 
> It might be worth talking about __foo as well as __foo__ or more likely
> just having your message point to __typeof__ instead, to avoid more
> postings from other surprised people :-).

The patch I committed refers to __typeof__.

zw

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
@ 2002-10-15 13:00 Ulrich Weigand
  0 siblings, 0 replies; 14+ messages in thread
From: Ulrich Weigand @ 2002-10-15 13:00 UTC (permalink / raw)
  To: jbuck; +Cc: gcc

Joe Buck wrote:

>Here's a third draft for GCC 3.2.1 release notes.  Please let me know
>about anything else that should be mentioned.

Could you please add the following three s390 specific PRs that
have been fixed for 3.2.1?  Thanks!

7370  ICE in fixup_var_refs_1 on s390x
7409  loop optimization generates wrong code on s390
8232  s390x: ICE when using bcmp with 'int' length argument


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: gcc 3.2.1 draft release notes, 3rd draft
@ 2002-10-15  5:19 Reichelt
  0 siblings, 0 replies; 14+ messages in thread
From: Reichelt @ 2002-10-15  5:19 UTC (permalink / raw)
  To: jbuck, gcc

Hi,

PR 7188 "Segfault with template class and recursive (incorrect)
initalizer list" is now listed in the C++ category.
The segfault is actually an ICE, so the bug should probably be listed in
the ICE category instead.

The description of PR 7160 could be a little more precise. How about:
ICE when optimizing branches without return value
(inspired by the comment in the testcase in
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01645.html)?

Greetings,
Volker Reichelt


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2002-10-22 21:20 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-14 17:38 gcc 3.2.1 draft release notes, 3rd draft Joe Buck
2002-10-15  1:27 ` Mark Mitchell
2002-10-15 10:10   ` Joe Buck
2002-10-15 11:33     ` Mark Mitchell
2002-10-15 19:11       ` Zack Weinberg
2002-10-15 21:19         ` Joe Buck
2002-10-18  4:48           ` Zack Weinberg
2002-10-18  5:17             ` Mark Mitchell
2002-10-18  7:42             ` John Marshall
2002-10-22 17:20               ` Zack Weinberg
2002-10-15  9:02 ` Alexandre Oliva
2002-10-15  9:18   ` Gabriel Dos Reis
2002-10-15  5:19 Reichelt
2002-10-15 13:00 Ulrich Weigand

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).