GCC 3.3

GCC 3.3

[Mark Mitchell]

We have about 50 open high-priority PRs representing regressions
against GCC 3.3.

I've heard a few people say that "all the open PRs are C++ PRs" -- but
that's clearly false, looking at the list below.  It's true that we
C++ folks have our work cut out for us, but there are plenty of back
end and optimizer issues in the list below.

At this point, I'm going to change the rules for the 3.3 branch
slightly.  In particular, compile-time improvement patches need to get
normal approval from a maintainer *and* a review by me.  I'm going to
be leery of anything that doesn't look obviously simple and correct to
me.  We've made a lot of good improvements in this regard, and there
are a few more patches I think we can get in, but it's time to focus
on the out-and-out crashes and bad code generation problems.

Please look through this list and see if you can't knock a few of
these out.

I think we are getting pretty close; some of these PRs are duplicates,
and some can get downgraded if we can't fix 'em readily.

Gaby, you would make my life a little simpler if you'd take some of
the high-priority bugs that are only 3.2 regressions and close them,
after applying patches to the 3.2 branch if you want to do that.
There are now a lot of 3.2-only PRs open, and it's hard to see what's
a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

=============================================================================================

10031	3.3/mainline c++ regression

10021	[3.2/3.3/3.4 regression] alias problem during loop pass on m68k

10017	[3.2/3.3/3.4 regression] ICE: unable to find a register to spill in class `GENERAL_REGS'

9936	[3.2/3.3 regression] ICE with local function and variable-length 2d array

9929	[3.3/3.4 regression] Can't find spill register

9928	[3.3/3.4 regression] ICE on duplicate enum declaration
	ebotcazou

9924	[3.2/3.3/3.4 regression] Multiple using statements for builtin functions not allowed

9886	[3.3/3.4 regression][IA64] ICE in final_scan_insn

9865	[3.2/3.3/3.4 regression] Template matching for reference types
	nathan

9853	[3.2/3.3/3.4 regression] miscompilation of non-constant structure initializer

9820	[3.3/3.4 regression] ice in build_baselink (templates)
	jason

9812	[3.2/3.3 regression] ICE in extract_insn, at recog.c:2148

9786	[3.2/3.3/3.4 regression] Ice in fixup_abnormal_edges with -fnon-call-exceptions -O2

9769	[3.2/3.3 regression] miscompilation with -freg-struct-return

9763	[<3.2,3.3,3.4> regression][sparc] Internal compiler error in emit-rtl.c (gen_reg_rxt)

9630	[3.2/3.3/3.4 regression] crash with -freg-struct-return in C++ code

9629	[3.2/3.3/3.4 regression] virtual inheritance segfault

9570	[3.3/3.4 regression] Assember error with -finline-functions with g++-3.3

9474	[3.2/3.3/3.4 regression] GCC freezes in compiling a weird code mixing <iostream> and <iostream.h>

9420	[3.2/3.3/3.4 regression] incomplete type incorrectly reported
	nathan

9357	[3.2/3.3/3.4 regression] SegFault with -fssa -funroll-loops -fprofile-arcs

9315	[3.2/3.3/3.4 regression] problems with overload resolution

9181	[3.2.1/3.3/3.4 regression] ICE with inline assembly in instantiate_virtual_regs_1, at function.c:3974

9123	[3.2/3.3/3.4 regression ] Internal compiler error in do_SUBST at combine.c:434

9091	[3.3 branch regression] Ada bootstrap failure on powerpc-linux

9016	[3.2/3.3/3.4 regression] Failure to consistently constant fold "constant" C++ objects

8964	[3.3/3.4 regression] [ABI] different mangling of names

8962	[3.3 regression] [CygWin] "-O2 -mmmx" makes gcc seg fault

8913	[3.3 regression] ICE in simplify_gen_subreg, at simplify-rtx.c

8866	[3.3/3.4 regression] Bug in switch statement code generation -- missing label

8808	[3.2/3.3 regression] Internal compiler error in extract_constrain_insn_cached

8805	[3.2/3.3/3.4 regression] compile time regression with many member variables

8803	[3.2/3.3/3.4 regression] Internal compiler error in instantiate_virtual_regs_1, at function.c:3974
8730	[3.2/3.3/3.4 regression] Cannot compile C function inside other C function

8634	[3.2/3.3 regression] incorrect code for inlining of memcpy under -O2

8457	[3.2/3.3 regression] ICE in generate_bytecode_insns, at java/jcf-write.c:1850
	aph

8396	[3.2/3.3/3.4 regression] [sparc] optimizer ICE

8361	[3.3/3.4 regression] C++ compile-time performance regression

8306	[3.2/3.3 regression] ICE for bitfield7_y.C in C++ compatibility tests

8300	[3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662

7916	[3.2/3.3/3.4 regression] ICE in instantiate_virtual_register_1

7817	[3.2/3.3 regression] Link to gcc man page in g++ man page incorrect

7257	[3.2/3.3/3.4 regression] -O3 -fverbose-asm does not display -flag-inline-functions
	ebotcazou

7189	[3.2/3.3 regression] gcc -O2 -Wall does not print ``control reaches end of non-void function'' warning
	steven

7086	[3.3/3.4 regression] compile time regression

7050	[3.2/3.3/3.4 regression] g++ segfaults on: (i ? get_string() : throw)
	jason

6871	[3.3/3.4 regression] const objects shouldn't be moved to .bss

6860	[3.2/3.3/3.4 regression] [arm-thumb] pre_insert_copy_insn

6798	[3.2/3.3/3.4 regression] very long compile time with large case-statement

6440	[3.2/3.3 regression] ice in template friend member function
	mmitchel

6387	[3.2/3.3 regression] -fpic -gdwarf-2 -g1 combination give ICE in dwarf2out

6262	[3.2/3.3/3.4 regression] gcc reports internal compiler error on legal code

2001	[3.2/3.3 regression] Inordinately long compile times in reload CSE regs

Re: GCC 3.3

[David Edelsohn]

	PR 9091 was fixed in December, but was not closed.  I just closed
it. 

	PR 9745 was not on your list, but is a high priority PR for GCC
3.3.  I sent a strawman patch earlier this month, but received no
feedback.  The problem ultimately comes down to a nasty aliasing problem
because the PowerPC frame pointer is not a fixed register.

David

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 13:44, David Edelsohn wrote:
> 	PR 9091 was fixed in December, but was not closed.  I just closed
> it. 

Thanks.

> 	PR 9745 was not on your list, but is a high priority PR for GCC
> 3.3.

In that case, please mark it as a [3.3 regression] in GNATS.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gaby, you would make my life a little simpler if you'd take some of
| the high-priority bugs that are only 3.2 regressions and close them,
| after applying patches to the 3.2 branch if you want to do that.
| There are now a lot of 3.2-only PRs open, and it's hard to see what's
| a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

Will take them.

-- Gaby

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 13:32, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> | Gaby, you would make my life a little simpler if you'd take some of
> | the high-priority bugs that are only 3.2 regressions and close them,
> | after applying patches to the 3.2 branch if you want to do that.
> | There are now a lot of 3.2-only PRs open, and it's hard to see what's
> | a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...
> 
> Will take them.

Thanks.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Geert Bosch]

On Tuesday, Mar 11, 2003, at 16:30 America/New_York, Mark Mitchell 
wrote:

>
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
>
> I've heard a few people say that "all the open PRs are C++ PRs" -- but
> that's clearly false, looking at the list below.  It's true that we
> C++ folks have our work cut out for us, but there are plenty of back
> end and optimizer issues in the list below.
>
...
>
> 9091	[3.3 branch regression] Ada bootstrap failure on powerpc-linux
>

This one has been fixed for a while (thanks David):
> State-Changed-From-To: analyzed->closed
> State-Changed-By: dje
> State-Changed-When: Tue Mar 11 21:36:00 2003
> State-Changed-Why:
>     Fixed with patch to define WIDEST_HARDWARE_FP_SIZE
>     on 2002-12-31

Re: GCC 3.3

[Steven Bosscher]

Op di 11-03-2003, om 22:30 schreef Mark Mitchell:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
> 
> I've heard a few people say that "all the open PRs are C++ PRs" -- but
> that's clearly false, looking at the list below.  It's true that we
> C++ folks have our work cut out for us, but there are plenty of back
> end and optimizer issues in the list below.

There used to be more C++ PRs, but the "C++ folks" have fixed so many
that it doesn't look so bad anymore.  Thanks!

> Gaby, you would make my life a little simpler if you'd take some of
> the high-priority bugs that are only 3.2 regressions and close them,
> after applying patches to the 3.2 branch if you want to do that.
> There are now a lot of 3.2-only PRs open, and it's hard to see what's
> a 3.3 PR and what's a 3.2 PR in GNATS.  This is GNATS' fault...

???
Go to Query, then look for high priority PRs that have "3.3" in the
synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
hi-pri PRs are now classified better than ever before!

That query gives me 58 PRs now; of these I know of three that look like
they're actually fixed or they have a patch pending.  9745 shows up in
this query.  Two weeks ago, there were 78 high priority PRs for 3.3, so
things are looking much better :-)

Greetz
Steven

Re: GCC 3.3

[Mark Mitchell]

> ???> Go to Query, then look for high priority PRs that have "3.3" in the
> synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> hi-pri PRs are now classified better than ever before!

Amazingly, I did not think of that.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Richard Earnshaw]

> > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > hi-pri PRs are now classified better than ever before!
> 
> Amazingly, I did not think of that.
> 

Unfortunately, that misses out a few that are marked as regressions, but 
aren't at high priority.  These are (if I've typed them in correctly):

Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
Low: 9163 5975

In addition there are several PRs which refer to 3.3 but are not marked as 
regressions.

R.

Re: GCC 3.3

[Eric Botcazou]

> Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162

The correct fix for PR opt/7675 would not be 3.3 material I think and the bug 
is really a corner case.

-- 
Eric Botcazou

Re: GCC 3.3

[Joe Buck]

On Wed, Mar 12, 2003 at 11:25:17AM +0000, Richard Earnshaw wrote:
> > > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > > hi-pri PRs are now classified better than ever before!
> > 
> > Amazingly, I did not think of that.
> > 
> 
> Unfortunately, that misses out a few that are marked as regressions, but 
> aren't at high priority.  These are (if I've typed them in correctly):
> 
> Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
> Low: 9163 5975
> 
> In addition there are several PRs which refer to 3.3 but are not marked as 
> regressions.

The right thing to do is to mark these as high priority and to put
the standard prefix in the Synopsis line.  I'll make a pass at this if
no one else has, but I'd want to confirm that these are still issues,
and, thanks to continued problems with subversions.gcc.org, I can't
update from CVS ("waiting for anoncvs's lock in /cvsroot/gcc/gcc" forever).

Re: GCC 3.3

[Mark Mitchell]

On Wed, 2003-03-12 at 09:58, Joe Buck wrote:
> On Wed, Mar 12, 2003 at 11:25:17AM +0000, Richard Earnshaw wrote:
> > > > ???> Go to Query, then look for high priority PRs that have "3.3" in the
> > > > synopsis.  How much easier can it be?  Thanks to (mostly) Wolfgang,
> > > > hi-pri PRs are now classified better than ever before!
> > > 
> > > Amazingly, I did not think of that.
> > > 
> > 
> > Unfortunately, that misses out a few that are marked as regressions, but 
> > aren't at high priority.  These are (if I've typed them in correctly):
> > 
> > Medium: 10024 9972 9848 9772 9594 9469 9311 8963 8960 7675 6162
> > Low: 9163 5975
> > 
> > In addition there are several PRs which refer to 3.3 but are not marked as 
> > regressions.
> 
> The right thing to do is to mark these as high priority and to put
> the standard prefix in the Synopsis line. 

Note further that at least a few of those may have been given less than
high priority on purpose; I've downgraded a couple of PRs.  When I do
that, there's always a note in the PR record.

Thanks for helping out with this!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Mike Stump]

On Tuesday, March 11, 2003, at 01:30 PM, Mark Mitchell wrote:
> At this point, I'm going to change the rules for the 3.3 branch
> slightly.  In particular, compile-time improvement patches need to get
> normal approval from a maintainer *and* a review by me.

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html

These patches solve a compile time performance regression that was 
introduced when contexting for GC went it and was used.  For my 
testcase it was a 31.3% speedup.  You previously OKed the work in:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02457.html

but Geoff wanted a few issues addressed, so I addressed them, but I 
never heard back from him, he's been busy.

The original patch, if you want to see the complete history, started 
with:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02451.html

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-03-11 at 16:04, Mike Stump wrote:
> On Tuesday, March 11, 2003, at 01:30 PM, Mark Mitchell wrote:
> > At this point, I'm going to change the rules for the 3.3 branch
> > slightly.  In particular, compile-time improvement patches need to get
> > normal approval from a maintainer *and* a review by me.
> 
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html
> 
> These patches solve a compile time performance regression that was 
> introduced when contexting for GC went it and was used. 

OK, go ahead and check these in, mainline and branch.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Mike Stump]

On Tuesday, March 11, 2003, at 07:36 PM, Mark Mitchell wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00591.html
>>
>> These patches solve a compile time performance regression that was
>> introduced when contexting for GC went it and was used.
>
> OK, go ahead and check these in, mainline and branch.

Done.  Thanks.  If anyone trips over prefetch not working, let us know. 
  I think this would be the first time it's been used in the compiler.  
I turned off that part of the patch for 3.3 to avoid any potential 
problems.

Re: GCC 3.3

[Steven Bosscher]

Hi Mark,

If you've not already looked into all high-priority 3.3 PRs, here's a
reference to four patches.  Also one patch seens to be fixed, and one
should maybe suspended...


On Tue 11-03-2003  22:30  Mark Mitchell wrote:
> 9928	[3.3/3.4 regression] ICE on duplicate enum declaration
> 	ebotcazou

PR c/9928
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00972.html)
OK'ed by rth but not commited yet)


> 9357	[3.2/3.3/3.4 regression] SegFault with -fssa -funroll-loops -fprofile-arcs

PR optimization/9357
This is an -fssa issue, and rtl-ssa is not officially supported (i.e. it
is known not.to work correctly in all cases).  Maybe this one should
just be suspended then?


> 8634	[3.2/3.3 regression] incorrect code for inlining of memcpy under -O2

PR optimization/8634
(Patch: http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00533.html)
Never reviewed.


> 7189	[3.2/3.3 regression] gcc -O2 -Wall does not print ``control reaches end of non-void function'' warning
> 	steven

PR optimization/7189
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00086.html)
This one is on the mainline already.


6942  [3.3 regression] Error detected at g-spipat.adb:4828:7 (cygwin)
(Was not in your list)

PR middle-end/6942
This problem is not present in trunk at Wed Mar 5 2003, keep an eye on
it (maybe put it in feedback).


> 6440	[3.2/3.3 regression] ice in template friend member function
> 	mmitchel

PR c++/6440
(Patch: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00423.html)
The PR is assigned to you but the patch is from Kriang Lerdsuwanakij. 
It also still needs to be reviewed (it's a week old now).


Greetz
Steven

Re: GCC 3.3

[law]

In message <1047430325.30643.154.camel@steven>, Steven Bosscher writes:
 >PR optimization/9357
 >This is an -fssa issue, and rtl-ssa is not officially supported (i.e. it
 >is known not.to work correctly in all cases).  Maybe this one should
 >just be suspended then?
That sounds like a wise idea to me.

jeff

Re: GCC 3.3

[Janis Johnson]

On Tue, Mar 11, 2003 at 01:30:58PM -0800, Mark Mitchell wrote:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.
> 
> Please look through this list and see if you can't knock a few of
> these out.

For anyone fixing these: let me know if you'd like me to identify the
patch that introduced the regression or, if applicable, the one that
fixed in in mainline, assuming it can be reproduced on i686-linux-gnu,
ia64-linux-gnu, powerpc-linux-gnu, or powerpc64-linux-gnu.  Keep in
mind that this isn't usually useful for old C++ regressions, and in
many other cases the patch turns out to be too extensive to be useful.
Sometimes it helps.

Janis

Re: GCC 3.3

[Janis Johnson]

On Tue, Mar 11, 2003 at 01:30:58PM -0800, Mark Mitchell wrote:
> 
> We have about 50 open high-priority PRs representing regressions
> against GCC 3.3.

I've changed the synopsis of optimization/6597 to show that it is a
regression in 3.3 and 3.4, but I didn't bump the priority.  This is an
ICE that shows up only with checking enabled, and I've only been able
to reproduce it on ia64-linux.  I'll let Mark decide whether it should
have a higher priority.  I verified last week that it still exists.

Janis

attribute(at)

[Piotr Wyderski]

Hello,

Often it's needed to specify an exact memory layout of a data
structure -- this feature is useful for low-level programmers,
because most hardware-dependent structures have exactly
specified member offsets. Currently it's necessary to use
ugly tricks, for example:

typedef struct {

    CHAR m_FieldAlignment[5];
    UINT32 m_Field;

}  __attribute__((packed))  XXX;

Here's a simple proposition of a new extension of the GCC
compiler. Usage:

#define AT(x) __attribute__((at(x)))

struct {

    UINT32 m_Field AT(10);
    CHAR m_SecondField[14] AT(1547);

} PACKED XXX;

Meaning: a field which has the attribute specified is placed
exactly at the offset (in other words: relatively to the structure's
base address, when the strcture is instantiated). Can be used
in nested structures:

struct {
    
    UINT32 m_X AT(0);

    struct {

        UINT64 m_Y AT(10);
    } Y;
} X;

X's ofset is 0, Y's offset is 14 (=sizeof(UINT32) + 10).

Is it possible to include this simple but very useful mechanism
to the future releases of GCC? I think that many low-level
developers would be very happy because of this extension.
This attribute could be also used by code written in C++,
when applied to a POD structure.

    Best regards
    Piotr Wyderski
   


Serwis www.logo.hoga.pl - sciagaj bajery na telefony
Nokia, Siemens, Alcatel, Ericsson, Motorola,Samsung
------------------------------------------------------------
Promocja!!! rabat 40 % na zakup mks_vir 2003 dla klientów Connect , którzy
posiadaja kupony rabatowe.

Re: GCC 3.3

[Eric Botcazou]

> The problem belongs to the definitions of PTHREAD_MUTEX_INITIALIZER and
> PTHREAD_COND_INITIALIZER in pthread.h in solaris 2.6 .
>
> To solve the problem I added the two following fixes in file
> inclhack.def:
>
> fix = {
>     hackname = solaris26_mutex_init;
>     select = '@\(#\)pthread.h' "[ \t]+1.16+[ \t]+[0-9/]+ SMI";
>     files = pthread.h;
>     c_fix = format;
>     c_fix_arg = "%1{{0},0},{0}%2\n";
>     c_fix_arg = "(^#define[ \t]+PTHREAD_MUTEX_INITIALIZER[ \t]+{[ \t]*)"
>
>                 "0,[ \t]*0" "(,.*)$";
>     test_text =
>     '#ident "@(#)pthread.h 1.16 97/05/05 SMI"'"\n"
>     "#define PTHREAD_MUTEX_INITIALIZER\t{0, 0, 0}[ \t]*\n";
> };
>
>
> fix = {
>     hackname = solaris26_cond_init;
>     select = '@\(#\)pthread.h' "[ \t]+1.16+[ \t]+[0-9/]+ SMI";
>     files = pthread.h;
>     c_fix = format;
>     c_fix_arg = "%1{{0},0}%2\n";
>     c_fix_arg = "(^#define[ \t]+PTHREAD_COND_INITIALIZER[ \t]+{[ \t]*)"
>                 "0" "(,.*)$";
>     test_text =
>     '#ident "@(#)pthread.h 1.16 97/05/05 SMI"'"\n"
>     "#define PTHREAD_COND_INITIALIZER\t{0, 0}[ \t]*\n";
> };
>
> I hope this will help you.

Sure. Many thanks!

I should have remembered this problem... this is PR target/7971.


DJ, what is the status of this PR?

I see this entry in the ChangeLog for 3.2.3:

2003-03-29  Albert Chin-A-Young  <china@thewrittenword.com>
	DJ Delorie  <dj at redhat dot com>,
	Bruce Korb  <bkorb at gnu dot org>

	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
	buggy Solaris mutex/cond initializers.
	(solaris_mutex_init): Rename to solaris_mutex_init_2.
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/pthread.h: Update.

and these entries on mainline:

2003-03-28  Albert Chin-A-Young  <china@thewrittenword.com>

	* gcc/fixinc/inclhack.def: Update solaris_mutex_init_1 to
	work on Solaris 2.5.1.

2003-03-22  DJ Delorie  <dj at redhat dot com>,
	Bruce Korb  <bkorb at gnu dot org>

	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
	buggy Solaris 2.6 mutex/cond initializers.
	(solaris_mutex_init): Rename to solaris_mutex_init_2.
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/pthread.h: Update.
	* fixinc/fixincl.c(initialize): be explicit about the default case
	and indicate verbose level when being very, very verbose.
	* fixinc/check.tpl(VERBOSE): provide a means for passing the value in

but none on the 3.3 branch?

-- 
Eric Botcazou

Re: GCC 3.3

[Benjamin Kosnik]

>2003-03-28  Albert Chin-A-Young  <china@thewrittenword.com>
>
>	* gcc/fixinc/inclhack.def: Update solaris_mutex_init_1 to
>	work on Solaris 2.5.1.
>
>2003-03-22  DJ Delorie  <dj at redhat dot com>,
>	Bruce Korb  <bkorb at gnu dot org>
>
>	* fixinc/inclhack.def (solaris_mutex_init_1): New; Fix
>	buggy Solaris 2.6 mutex/cond initializers.
>	(solaris_mutex_init): Rename to solaris_mutex_init_2.
>	* fixinc/fixincl.x: Regenerate.
>	* fixinc/tests/base/pthread.h: Update.
>	* fixinc/fixincl.c(initialize): be explicit about the default case
>	and indicate verbose level when being very, very verbose.
>	* fixinc/check.tpl(VERBOSE): provide a means for passing the value in
>
>but none on the 3.3 branch?

You should ask Bruce to queue this for 3.3.1.

-benjamin

GCC 3.3

[Mark Mitchell]

I'm going to review Kean's patch to deal with rcs_id, and hopefully
check that in this morning.

I'm going to wait for Richard and David to commit the changes I've
approved there.

And then, I'm running the prerelease; no ifs, ands, or buts.

If there is some incredibly vital patch, it can go in to the next
prerelease, but things like "glibc really wants this" aren't going to
make it in that round.

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3

[Eric Botcazou]

> And then, I'm running the prerelease; no ifs, ands, or buts.

What of "what ofs"? :-)

> If there is some incredibly vital patch, it can go in to the next
> prerelease, but things like "glibc really wants this" aren't going to
> make it in that round.

What of trivial patches posted three weeks ago:

	http://gcc.gnu.org/ml/gcc/2003-04/msg00611.html

with some support from a maintainer:

	http://gcc.gnu.org/ml/gcc/2003-04/msg00632.html

and for some reason still unreviewed?

-- 
Eric Botcazou

Re: GCC 3.3

[Mark Mitchell]

On Mon, 2003-05-05 at 11:21, Eric Botcazou wrote:
> > And then, I'm running the prerelease; no ifs, ands, or buts.
> 
> What of "what ofs"? :-)

Nope, not those either. :-)

> > If there is some incredibly vital patch, it can go in to the next
> > prerelease, but things like "glibc really wants this" aren't going to
> > make it in that round.
> 
> What of trivial patches posted three weeks ago:

The problem is that if I do not draw the line, this process will go on
forever.  I am 100% confident that there are at least ten other
"trivial", good, useful patches for issues that someone will care about
lying around out there.  

That's sad -- but I've given plenty of warnings.  

In our current process, it's up to maintainers to review these things in
a timely fashion.

> 	http://gcc.gnu.org/ml/gcc/2003-04/msg00611.html
> 
> with some support from a maintainer:

If this patch is reviewed -- and tested on at least three platforms that
use this Makefile target -- it can go in after the first prerelease.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

> If there is some incredibly vital patch, it can go in to the next
> prerelease, but things like "glibc really wants this" aren't going to
> make it in that round.

Sorry for arriving so late in the game but, as the machines at stake are not 
exactly fast, I was previously concentrating on the 3.2.3 release and then 
left for two weeks...

The bad news: we have a bunch of C++ regressions on sparc-sun-solaris2.5.1

3.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00337.html
3.2.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00894.html

and sparc-sun-solaris2.6

3.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00338.html
3.2.3pre: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00894.html

(sparc-sun-solaris2.[7-9] are clean).

The good news: they appear to have the same origin (in libstdc++-v3), see the 
attached log file.

I'm going to try to debug them but, as I'm not an expert of libstdc++-v3 at 
all, any help would be *greatly* appreciated (emphasis by me :-).

-- 
Eric Botcazou

[-- Attachment #2: solaris2.6-c++bug.log --]
[-- Type: text/x-log, Size: 13418 bytes --]

Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/init/array4.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/eric/g
cc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/gcc-3_
3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/libstdc
++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/backward -
I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-length=0
-ansi -pedantic-errors -Wno-long-long  -S  -o array4.s    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/in
it/array4.C:8:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/template/friend.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-branc
h/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/er
ic/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/gc
c-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/lib
stdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/backwa
rd -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-length=
0   -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-branch/spar
c-sun-solaris2.6//libiberty  -lm   -o friend.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/te
mplate/friend.C:5:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.dg/template/friend10.C  -nostdinc++ -I/opt/build/eric/gcc-3_3-bra
nch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/build/
eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build/eric/
gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch/src/l
ibstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/include/back
ward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage-lengt
h=0   -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-branch/
sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-branch/sp
arc-sun-solaris2.6//libiberty  -lm   -o ./friend10.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.dg/te
mplate/friend10.C:9:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.old-deja/g++.benjamin/15071.C  -nostdinc++ -I/opt/build/eric/gcc-
3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt
/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/buil
d/eric/gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branc
h/src/libstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/inclu
de/backward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessag
e-length=0  -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-b
ranch/sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-bra
nch/sparc-sun-solaris2.6//libiberty  -lstdc++ -lm   -o /opt/build/eric/gcc-3_3-b
ranch/gcc/testsuite/g++-benjamin-15071-C.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.old-d
eja/g++.benjamin/15071.C:5:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1


Executing on host: /opt/build/eric/gcc-3_3-branch/gcc/testsuite/../g++ -B/opt/bu
ild/eric/gcc-3_3-branch/gcc/testsuite/../ /opt/build/eric/gcc-3_3-branch/src/gcc
/testsuite/g++.old-deja/g++.brendan/copy9.C  -nostdinc++ -I/opt/build/eric/gcc-3
_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/sparc-sun-solaris2.6 -I/opt/
build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include -I/opt/build
/eric/gcc-3_3-branch/src/libstdc++-v3/libsupc++ -I/opt/build/eric/gcc-3_3-branch
/src/libstdc++-v3/libio -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/includ
e/backward -I/opt/build/eric/gcc-3_3-branch/src/libstdc++-v3/testsuite -fmessage
-length=0  -ansi -pedantic-errors -Wno-long-long    -L/opt/build/eric/gcc-3_3-br
anch/sparc-sun-solaris2.6//libstdc++-v3/src/.libs -L/opt/build/eric/gcc-3_3-bran
ch/sparc-sun-solaris2.6//libiberty  -lstdc++ -lm   -o /opt/build/eric/gcc-3_3-br
anch/gcc/testsuite/g++-brendan-copy9-C.exe    (timeout = 300)
In file included from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/stl_alloc.h:89,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/memory:55,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/string:48,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/locale_classes.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/bits/ios_base.h:47,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ios:49,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/ostream:45,
                 from /opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstd
c++-v3/include/iostream:45,
                 from /opt/build/eric/gcc-3_3-branch/src/gcc/testsuite/g++.old-d
eja/g++.brendan/copy9.C:2:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In constructor `std::_Refcount_Base::_Refcount_Base(unsigned int)':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:74: error: brace-enclosed initializer used to initialize `uint8_t'
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: At global scope:
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h: In instantiation of `__gthread_mutex_t std::_Swap_lock_struct<0>::_
S_swap_lock':
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:122:   instantiated from here
/opt/build/eric/gcc-3_3-branch/sparc-sun-solaris2.6/libstdc++-v3/include/bits/st
l_threads.h:115: error: brace-enclosed initializer used to initialize `uint8_t'
compiler exited with status 1

Re: GCC 3.3

[Ulrich Weigand]

Jan Hubicka wrote:

>I commit the attached patch.  Urlich does this solve the problems you
>are seeing?

Yes.  (This is exactly how I was solving the problem locally while
waiting for a proper fix, so I don't need to test it again ;-))


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

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 12:18, Ulrich Weigand wrote:
> 
> Jan Hubicka wrote:
> 
> >I commit the attached patch.  Urlich does this solve the problems you
> >are seeing?
> 
> Yes.  (This is exactly how I was solving the problem locally while
> waiting for a proper fix, so I don't need to test it again ;-))

Great; I've now marked this as a 3.4, but not 3.3, PR.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Benjamin Kosnik]

libstdc++/10276

There are various unresolved issues with the named locale caching,
including memory leaks, and potential ABI issues. I thought I'd have
more time to work on this, but I guess four days is better than four hours.

I'm now on this 100%, and will give you status daily.

-benjamin

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 09:09, Benjamin Kosnik wrote:
> 
> libstdc++/10276
> 
> There are various unresolved issues with the named locale caching,
> including memory leaks, and potential ABI issues. I thought I'd have
> more time to work on this, but I guess four days is better than four hours.

This isn't marked as a 3.3 regression; please update it's synopsis so
that I can see it.  Otherwise, I will forget.

If this only happens to be people using GCC in non-default locales, it's
not the end of the world.  The ABI issues are more important than the
memory leaks.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Benjamin Kosnik]

>This isn't marked as a 3.3 regression; please update it's synopsis so
>that I can see it.  Otherwise, I will forget.

Done.

>If this only happens to be people using GCC in non-default locales, it's
>not the end of the world.  The ABI issues are more important than the
>memory leaks.

No. It's all streams including the standard "C" objects like cout, in
addition to the ABI issues.

-benjamin

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 10:06, Benjamin Kosnik wrote:
> 
> >This isn't marked as a 3.3 regression; please update it's synopsis so
> >that I can see it.  Otherwise, I will forget.
> 
> Done.

Thanks.

Yes, I agree that this is critical; please do keep me apprised of
progress.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Giovanni Bajo]

Hi Mark,

for us windows users, there is an important regression in winnt.c, see
pr/7910. This has been broken for many months now, it has been reported in
at least 6 different PRs, from different people and in different (and always
legal) code. I guess that it's breaking a lot of windows-specific code out
there.

You submitted a patch for this and later reverted it. Maybe is it possible
to come up with a proper patch before 3.3 is released?

Giovanni Bajo

Re: GCC 3.3

[Mark Mitchell]

> You submitted a patch for this and later reverted it. Maybe is it possible
> to come up with a proper patch before 3.3 is released?

I'm not planning to volunteer my time to work on this particular bug.

(Yes, all the nuances in that sentence are intentional.)

It would be great if this bug were fixed, so I've copied Christopher
Faylor (the Windows port maintainer) on this email.

Christopher, would you take a look at PR 7910 ASAP?

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Christopher Faylor]

On Tue, Apr 29, 2003 at 09:34:13AM -0700, Mark Mitchell wrote:
>> You submitted a patch for this and later reverted it. Maybe is it possible
>> to come up with a proper patch before 3.3 is released?
>
>I'm not planning to volunteer my time to work on this particular bug.
>
>(Yes, all the nuances in that sentence are intentional.)
>
>It would be great if this bug were fixed, so I've copied Christopher
>Faylor (the Windows port maintainer) on this email.
>
>Christopher, would you take a look at PR 7910 ASAP?

I'll look at it but it won't be ASAP.  I'd choose to volunteer my time
but my time is not volunteerable for the extended period that would
be required for this bug.

cgf

Re: gcc 3.3

[Wolfgang Bangerth]

Mark,
the only thing that comes to my mind is PR 9393 (the name mangling for 
anonymous namespace non-variability thing). Geoff applied a patch to 
mainline on Apr 12th, but not to 3.3. It's not exactly small, though.

I don't feel very strongly about it, having discovered yesterday that icc 
has the same bug. So we have to work around that anyway in our code :-)

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: gcc 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 08:08, Wolfgang Bangerth wrote:
> Mark,
> the only thing that comes to my mind is PR 9393 (the name mangling for 
> anonymous namespace non-variability thing). Geoff applied a patch to 
> mainline on Apr 12th, but not to 3.3. It's not exactly small, though.

I think we'll pass on that one, but thanks.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: gcc 3.3

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> On Tue, 2003-04-29 at 08:08, Wolfgang Bangerth wrote:
> > Mark,
> > the only thing that comes to my mind is PR 9393 (the name mangling for 
> > anonymous namespace non-variability thing). Geoff applied a patch to 
> > mainline on Apr 12th, but not to 3.3. It's not exactly small, though.
> 
> I think we'll pass on that one, but thanks.

Oh, rats, I forgot to actually commit that patch.  Well, too late now,
but we can put it in for 3.3.1.

The patch is pretty localised, but it changes configury which is
probably inappropriate at this point.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC 3.3

[Ulrich Weigand]

Mark Mitchell wrote:

>If you know of a regression for which you think we should hold the
>release:

There is a serious regression on s390 (Linux kernel silently
miscompiled).  See optimization/10536.

This is a regression over 3.2, introduced by this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html

It can be fixed either by reverting that patch, or else by this fix:
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
(which has not yet been approved).


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

Re: GCC 3.3

[Jan Hubicka]

> Mark Mitchell wrote:
> 
> >If you know of a regression for which you think we should hold the
> >release:
> 
> There is a serious regression on s390 (Linux kernel silently
> miscompiled).  See optimization/10536.
> 
> This is a regression over 3.2, introduced by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html
> 
> It can be fixed either by reverting that patch, or else by this fix:
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
> (which has not yet been approved).

Mark,
reverting of the patch is safe as the patch is purely compilation time
optimization.  I also tested the proposer proper fix relatively
troroughly in SuSE's internal compiler and it appears to cause no
problems as well. 

Honza

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 07:02, Jan Hubicka wrote:
> > Mark Mitchell wrote:
> > 
> > >If you know of a regression for which you think we should hold the
> > >release:
> > 
> > There is a serious regression on s390 (Linux kernel silently
> > miscompiled).  See optimization/10536.
> > 
> > This is a regression over 3.2, introduced by this patch:
> > http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01070.html
> > 
> > It can be fixed either by reverting that patch, or else by this fix:
> > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01318.html
> > (which has not yet been approved).
> 
> Mark,
> reverting of the patch is safe as the patch is purely compilation time
> optimization.  I also tested the proposer proper fix relatively
> troroughly in SuSE's internal compiler and it appears to cause no
> problems as well. 

I don't understand your new patch:

! 	  /* Do not delete instructions initializing operands needed by dead
! 	     instruction with side effects.  */
! 	  || (!counts[REGNO (x)] && incr > 0
! 	      && insn_live_p (insn, NULL)))
 
First, INSN is live -- not dead, given that insn_live_p holds.

Second, no deletion is taking place here.
  
Third, checking incr > 0 is pointless, since all that happens if the
condition is true is:

  counts[REGNO (x)] += incr;

Fourth, why check !counts[REGNO (x)]?

I think you want something more like:

  /* If this instruction is live, then even modifications to the  
destination register matter. */
  || insn_live_p (insn, NULL)

But then, the comment above the entire function needs to change, since
it explicitly says that modifications to the destination register don't
matter.

In light of this, please revert your original patch on the 3.3 branch,
but proceed with fixing it on the mainline.  We can consider this
optimization for 3.3.1 if it is stable by then.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Jan Hubicka]

> I don't understand your new patch:
> 
> ! 	  /* Do not delete instructions initializing operands needed by dead
> ! 	     instruction with side effects.  */
> ! 	  || (!counts[REGNO (x)] && incr > 0
> ! 	      && insn_live_p (insn, NULL)))
>  
> First, INSN is live -- not dead, given that insn_live_p holds.

It is not live, just it is undeletable because it has side effects or
something else.  insn_live_p checks that.
> 
> Second, no deletion is taking place here.

Yes, but we have to increase the counter in order to avoid other
deletions to happen (all values used by this insn must appear live.  All
the test does it to bypass values both used and initialized by the insn
so the insn is deleted entirely in the case the values are not elsewhere
like in dead induction variable)
>   
> Third, checking incr > 0 is pointless, since all that happens if the
> condition is true is:
> 
>   counts[REGNO (x)] += incr;

incr is either 1 or -1.
> 
> Fourth, why check !counts[REGNO (x)]?
This is just optimization - we don't have to call that expensive
function when the instruction is live for another reason already.
> 
> I think you want something more like:
> 
>   /* If this instruction is live, then even modifications to the  
> destination register matter. */
>   || insn_live_p (insn, NULL)

No, modifications never matters, just uses.
> 
> But then, the comment above the entire function needs to change, since
> it explicitly says that modifications to the destination register don't
> matter.
> 
> In light of this, please revert your original patch on the 3.3 branch,
> but proceed with fixing it on the mainline.  We can consider this
> optimization for 3.3.1 if it is stable by then.

OK.  My CVS access is deadly slow here in Barcelona, but I will try to
do it tonight.

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 12:00, Jan Hubicka wrote:
> > I don't understand your new patch:
> > 
> > ! 	  /* Do not delete instructions initializing operands needed by dead
> > ! 	     instruction with side effects.  */
> > ! 	  || (!counts[REGNO (x)] && incr > 0
> > ! 	      && insn_live_p (insn, NULL)))
> >  
> > First, INSN is live -- not dead, given that insn_live_p holds.
> 
> It is not live, just it is undeletable because it has side effects or
> something else.  insn_live_p checks that.

The bottom line is that I think this new code needs considerably more
explanation; something like:

/* If the instruction is live -- or if it has side effects that must  be
preserved -- and ..., then we update COUNTS, even if the register in use
is the destination register because ... */

That last part is still in conflict with the heading for the function,
which says "Don't count a usage of DEST," so that needs to be changed as
well.

If checking counts[REGNO(x)] is an optimization, then the actual count
doesn't seem to matter much; it's just whether or not it's zero. 
(Because you're only going to adding INCR sometimes.)  If that's true,
then the whole function ought to be changed so that rather than adding
incr, you're just setting a flag.

> OK.  My CVS access is deadly slow here in Barcelona, but I will try to
> do it tonight.

If you cannot, please let me know so that I can do it.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Jan Hubicka]

> On Tue, 2003-04-29 at 12:00, Jan Hubicka wrote:
> > > I don't understand your new patch:
> > > 
> > > ! 	  /* Do not delete instructions initializing operands needed by dead
> > > ! 	     instruction with side effects.  */
> > > ! 	  || (!counts[REGNO (x)] && incr > 0
> > > ! 	      && insn_live_p (insn, NULL)))
> > >  
> > > First, INSN is live -- not dead, given that insn_live_p holds.
> > 
> > It is not live, just it is undeletable because it has side effects or
> > something else.  insn_live_p checks that.
> 
> The bottom line is that I think this new code needs considerably more
> explanation; something like:
> 
> /* If the instruction is live -- or if it has side effects that must  be
> preserved -- and ..., then we update COUNTS, even if the register in use
> is the destination register because ... */
> 
> That last part is still in conflict with the heading for the function,
> which says "Don't count a usage of DEST," so that needs to be changed as
> well.

Yes, the original code was in conflict as well, so I didn't noticed that
when doing the patch.
> 
> If checking counts[REGNO(x)] is an optimization, then the actual count
> doesn't seem to matter much; it's just whether or not it's zero. 
> (Because you're only going to adding INCR sometimes.)  If that's true,
> then the whole function ought to be changed so that rather than adding
> incr, you're just setting a flag.

On the deeper tought this is probably wrong - some other instruction
that did use the counter may get removed but we still should not remove
the induction variable.
> 
> > OK.  My CVS access is deadly slow here in Barcelona, but I will try to
> > do it tonight.
> 
> If you cannot, please let me know so that I can do it.

Somehow the net is in good shape today.

I will prepare updated patch...

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

Re: GCC 3.3

[Jan Hubicka]

> In light of this, please revert your original patch on the 3.3 branch,
> but proceed with fixing it on the mainline.  We can consider this
> optimization for 3.3.1 if it is stable by then.
I commit the attached patch.  Urlich does this solve the problems you
are seeing?

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 1.16114.2.493
diff -c -3 -p -r1.16114.2.493 ChangeLog
*** ChangeLog	29 Apr 2003 18:46:56 -0000	1.16114.2.493
--- ChangeLog	29 Apr 2003 19:07:42 -0000
***************
*** 1,3 ****
--- 1,7 ----
+ Tue Apr 29 21:07:00 CEST 2003  Jan Hubicka  <jh@suse.cz>
+ 
+ 	* cse.c (count_reg_usage): Revert my previous patch.
+ 	
  2003-04-29  Zack Weinberg  <zack@codesourcery.com>
  
  	* config.gcc: Install obsolete target list for GCC 3.3.
Index: cse.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.244.2.1
diff -c -3 -p -r1.244.2.1 cse.c
*** cse.c	1 Apr 2003 19:17:10 -0000	1.244.2.1
--- cse.c	29 Apr 2003 19:07:43 -0000
*************** count_reg_usage (x, counts, dest, incr)
*** 7528,7535 ****
        /* Unless we are setting a REG, count everything in SET_DEST.  */
        if (GET_CODE (SET_DEST (x)) != REG)
  	count_reg_usage (SET_DEST (x), counts, NULL_RTX, incr);
        count_reg_usage (SET_SRC (x), counts,
! 		       SET_DEST (x),
  		       incr);
        return;
  
--- 7528,7542 ----
        /* Unless we are setting a REG, count everything in SET_DEST.  */
        if (GET_CODE (SET_DEST (x)) != REG)
  	count_reg_usage (SET_DEST (x), counts, NULL_RTX, incr);
+ 
+       /* If SRC has side-effects, then we can't delete this insn, so the
+ 	 usage of SET_DEST inside SRC counts.
+ 
+ 	 ??? Strictly-speaking, we might be preserving this insn
+ 	 because some other SET has side-effects, but that's hard
+ 	 to do and can't happen now.  */
        count_reg_usage (SET_SRC (x), counts,
! 		       side_effects_p (SET_SRC (x)) ? NULL_RTX : SET_DEST (x),
  		       incr);
        return;
  

GCC 3.3

[Mark Mitchell]

As of 5PM PST tomorrow, all non-documentation changes to the 3.3 branch
will require my explicit approval.

I plan to make the first prerelease tarball shortly thereafter.

In my judgement, the current set of regressions against 3.3 contain no
show-stoppers.  There are certainly bugs that would ideally be fixed,
but I do not see anything that looks particularly worse than any other
release of GCC -- and there are a ton of fixes and improvements.

If you know of a regression for which you think we should hold the
release:

(1) Make sure that there is an open, high-priority PR for your problem
with 3.3 in the title.  If there is not such a PR, create one.  Do not
send me email before creating a PR; I cannot keep track of such emails.

(2) After making sure that a PR exists, tell me the number of the PR,
and why you think it is critically important to be fixed.  If there is a
patch available, please tell me that as well.  Holding up the release,
for a PR for which no patch is available, isn't very likely to happen;
you'll have to make a very strong argument.

(3) If I indicate that the PR is not worth holding the release, and you
believe otherwise, let me know; I will forward your request to the GCC
Steering Committee.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Kaveh R. Ghazi]

 > In my judgement, the current set of regressions against 3.3 contain no
 > show-stoppers.

What about compile-time regressions?

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC 3.3

[Steven Bosscher]

Op di 29-04-2003, om 16:44 schreef Kaveh R. Ghazi:
> 
>  > In my judgement, the current set of regressions against 3.3 contain no
>  > show-stoppers.
> 
> What about compile-time regressions?

Seems a bit too late to try and take care of that now, don't you think? 

Gerald and others have shown, there is no single patch or a small set of
patches that we can blame the slowdown on; instead GCC consistently
slowed down over a period that spans at least two years: 3.2 was slower
than 3.1, which in turn was slower than 3.0, etc.

So those compile time regressions will not be fixed in a matter of days,
and weeks or months seems unacceptable.  Let's please just put out 3.3
and move on to make 3.4 a much better (includes: faster) compiler than
3.3.

Besides, your GC params patch compensates for most of the slowdown.   
GCC 3.3 actually is a bit faster than 3.2 for the code I've tried it
on.  Only C++ really is somewhat slower.

Greetz
Steven




> 
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC 3.3

[Mike Stump]

On Tuesday, April 29, 2003, at 08:16 AM, Steven Bosscher wrote:
> Gerald and others have shown, there is no single patch or a small set 
> of
> patches that we can blame the slowdown on; instead GCC consistently
> slowed down over a period that spans at least two years: 3.2 was slower
> than 3.1, which in turn was slower than 3.0, etc.

For one benchmark we have, between 3.1 and 3.3, there were two patches 
that caused compile time speed regressions, the second was small and 
was eventually fixed or worked around with the physmem patch.  The 
first, was a ~30% speed regression in one tiny little patch.  This bug 
remains unfixed on the 3.3 branch.

Re: GCC 3.3

[Steven Bosscher]

Op wo 30-04-2003, om 21:37 schreef Mike Stump:
> For one benchmark we have, between 3.1 and 3.3, there were two patches 
> that caused compile time speed regressions, the second was small and 
> was eventually fixed or worked around with the physmem patch.  The 
> first, was a ~30% speed regression in one tiny little patch.  This bug 
> remains unfixed on the 3.3 branch.

I think you have us _all_ wondering now: Which patch was that "first
patch" you talk about?  :-)

Greetz
Steven

Re: GCC 3.3

[Mike Stump]

On Wednesday, April 30, 2003, at 12:41 PM, Steven Bosscher wrote:
> Op wo 30-04-2003, om 21:37 schreef Mike Stump:
>> For one benchmark we have, between 3.1 and 3.3, there were two patches
>> that caused compile time speed regressions, the second was small and
>> was eventually fixed or worked around with the physmem patch.  The
>> first, was a ~30% speed regression in one tiny little patch.  This bug
>> remains unfixed on the 3.3 branch.
>
> I think you have us _all_ wondering now: Which patch was that "first
> patch" you talk about?  :-)

http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00530.html

It was much talked about in Feb:

http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01245.html

Re: GCC 3.3

[Mark Mitchell]

On Tue, 2003-04-29 at 07:44, Kaveh R. Ghazi wrote:
> 
>  > In my judgement, the current set of regressions against 3.3 contain no
>  > show-stoppers.
> 
> What about compile-time regressions?

Yes, there are some.  There are some progressions, too.

Some of the ideas I have are too invasive for the release branch; for
example, I want to go another round on the exceptions/inlining
interaction, but that's probably not a 3.3 change.

Fundamentally, I don't think there's much more we can do without just
waiting around hoping someone will fix things.  

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Gerald Pfeifer]

On Tue, 29 Apr 2003, Steven Bosscher wrote:
>> What about compile-time regressions?
> Seems a bit too late to try and take care of that now, don't you think?
>
> Gerald and others have shown, there is no single patch or a small set of
> patches that we can blame the slowdown on; instead GCC consistently
> slowed down over a period that spans at least two years: 3.2 was slower
> than 3.1, which in turn was slower than 3.0, etc.

There are two major sources of frustration here, affecting at least me
(as a user) and Mark (as maintainer and release manager).

> So those compile time regressions will not be fixed in a matter of days,
> and weeks or months seems unacceptable.  Let's please just put out 3.3
> and move on to make 3.4 a much better (includes: faster) compiler than
> 3.3.

1. I reported these performance regressions before the release of GCC 3.0,
   about two years ago

     http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3083

   and spent a significant amount of time (surely several man days)
   following this issue, as have others including yourself and Kaveh).

   Still, now close to GCC 3.3, the situation is as bad as:

      http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361

                    -O0         -O1          -O2        -O3
       GCC 3.0.4    27.95       44.52        56.57      56.48
      3.2-branch    29.87 +7%   54.28 +22%   70.95 +25% 75.29 +33%
      3.3-branch    29.09 +4%   57.11 +30%   78.99 +40% 81.61 +44%

   (and this completely ignores GCC 2.95, which was _vastly_ faster).

   > Only C++ really is somewhat slower.

   That's an euphemism.

2. Mark _has_ contributed quite a couple of performance improvements,
   (and so have others).

   But just because he is release manager and C++ maintainer, nobody can
   sensibly demand that he fixes all performance issues showing up from
   C++ code by himself; even more so if many advances of his are more
   than offset by the creeping slowdown throughout the compiler.

So, in the end, I suppose that currently both Mark and myself are somehow
frustrated (at least that's how I understood his reply).

Obviously, the picture is not as simple as drafted above, many others have
contributed most welcome performance improvements (even if in the end, we
lost), and some of the slowdowns were for correctness and optimization
(even if neither applied to my code at least).

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCC 3.3

[Mark Mitchell]

> 2. Mark _has_ contributed quite a couple of performance improvements,
>    (and so have others).
> 
>    But just because he is release manager and C++ maintainer, nobody can
>    sensibly demand that he fixes all performance issues showing up from
>    C++ code by himself; even more so if many advances of his are more
>    than offset by the creeping slowdown throughout the compiler.
> 
> So, in the end, I suppose that currently both Mark and myself are somehow
> frustrated (at least that's how I understood his reply).

I just don't think that we're going to be able to fix this for 3.3 given
where we presently are.

In practice, we often have a hard time getting people to fix correctness
regressions that they have introduced; compile-time regressions will be
even tougher, and they're tougher to pin on a particular person.  If I
fix a bug, but introduce a 0.25% slowdown, is that a net win or not? 
What if I speed up some piece of generated code by 1%?  When we still
have quadratic algorithms in the compiler, should we worry about my
0.25% slowdown?  Maybe we should invest in fixing those algorithms
instead -- but that requires major work, and we can't expect someone
who's just fixing a bug somewhere to do that.

The good news is that LANL is interested in seeing the C++ compiler run
faster, so Zack and Nathan and I *are* looking at these issues, from a
variety of different angles.

We are lucky in that LANL and Apple (among others, perhaps) are actively
supporting improvements in this area.  

I remain hopeful.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: GCC 3.3

[Gerald Pfeifer]

On Thu, 30 Apr 2003, Mark Mitchell wrote:
> I just don't think that we're going to be able to fix this for 3.3 given
> where we presently are.

I cannot really disagree, even though we bailed out before 3.0, we
bailed out before 3.1, and now we bail out before 3.3 again.

(The fact that we would be even slower without your various compile-time
improvements based on the examples I provided makes this even worse,
somehow.)

However, I take this as a clear indication that we need to rethink our
release process -- we cannot expect intricate issues like compile-time
performance to be solved on a release-branch, that's the resumé, I'd say,
so we must identify and take care of them before.

> The good news is that LANL is interested in seeing the C++ compiler run
> faster, so Zack and Nathan and I *are* looking at these issues, from a
> variety of different angles.
>
> We are lucky in that LANL and Apple (among others, perhaps) are actively
> supporting improvements in this area.

Good news!

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCC 3.3

[Scott Robert Ladd]

Mark Mitchell wrote:
> As of 5PM PST tomorrow, all non-documentation changes to the 3.3 branch
> will require my explicit approval.

Good move. I'm using the 04/21 snapshot of 3.3 at the moment; my code
thinks it is very solid.

I've been holding off publishing my next set of gcc-vs-Intel benchmarks
(a new test suite) until 3.3 is out. I'm also doing a feature-by-feature
comparison for ia32 developers -- so comparing gcc 3.3. against Intel
7.1 seems logical.

..Scott

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)

Re: GCC 3.3

[Laurent Guerby]

I just submitted PR ada/10546 for the tasking change
to get things working on all LinuxThread version
included those shipped with Red Hat Linux 9.

The 3.2.3 patch applies cleanly to 3.3 since
the file 5iosinte.ads hasn't changed between 3.2 and 3.3
(but for RCS Tag removal).

I need to test it on older glibc Linux systems if it
is okayed in principle for 3.3, I have access
to a slow machine so this will take a while,
let me know of your decision.

-- 
Laurent Guerby <guerby@acm.org>

Re: GCC 3.3

[Mark Mitchell]

> I need to test it on older glibc Linux systems if it
> is okayed in principle for 3.3, I have access
> to a slow machine so this will take a while,
> let me know of your decision.

It would be good to get this in, so get started on your testing ASAP.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.3

[Arnaud Charlet]

> I just submitted PR ada/10546 for the tasking change
> to get things working on all LinuxThread version
> included those shipped with Red Hat Linux 9.

Note that I've just included a fix for redhat 9 tasking on act's tree,
so I'd suggest you pick up this change (tomorrow, after the mirror) instead,
at least for the HEAD.

For the 3.3 branch, your previous patch is fine (now, you may want for
consistency to use the same approach on both branches).

Arno

Re: GCC 3.3

[John David Anglin]

Hi Mark,

PR 10024 wasn't on your list.  It is marked as a 3.3 regression.

There's also ada/9953.  It's not marked high or as a 3.3 regression.
Ada fails to build under hpux 10.20 on 3.3 because the 3.2 version
of libgnat uses a call to a system routine that's not available under
10.X.  The routine is part of the hpux 11.X unwind library and it's
used for exception support.  I am not sure whether this PR should
be high priority.  The main reason on my part to fix the build under
hpux 10.20 is that it is quite challenging to do the initial
bootstrap under hpux.  It involves starting from a version of gcc 2.8.1
which is rather broken.  I may be able to bootstrap ada under hpux 11
by bring the key tools over from hpux 10 but I haven't tried it.  I
believe the ACT people are working on this PR and I am hopeful that
there will be a fix.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: GCC 3.3

[Olivier Hainque]

John David Anglin wrote:
> There's also ada/9953
[...]
> I believe the ACT people are working on this PR and I am hopeful that
> there will be a fix.

 Indeed. A patch will be submitted shortly.

 Olivier

Re: GCC 3.3

[Olivier Hainque]

Hello again,

Just a small clarification:

> Ada fails to build under hpux 10.20 on 3.3 because the 3.2 version
> of libgnat uses a call to a system routine that's not available under
> 10.X.

 Right.

> The routine is part of the hpux 11.X unwind library and it's
> used for exception support.

 The routine is actually not used for exception support per se, but only for
 the computation of call-chain backtraces.

 It turns out that it is most often used together with exceptions, to attach
 to exception occurrences a traceback describing the call-chain at the point
 of the raise. 

 This is optional, however, and missing this feature does not prevent the base
 exception support to work.





 

gcc 3.3

[Chris M. Hickman]

I didn't see this addressed on the site...will 3.3 be binary compatible 
with 3.2 (unlike 3.2>3.1)?

Thanks for any info you can provide.

Chris

Re: gcc 3.3

[Fergus Henderson]

On 30-Jul-2002, Chris M. Hickman <twoheadedboy@stonepool.com> wrote:
> I didn't see this addressed on the site...will 3.3 be binary compatible 
> with 3.2 (unlike 3.2>3.1)?

The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
that all the ABI bugs have now been caught, but no-one knows for sure.

In addition, the libstdc++ ABI is not yet stable, so it is very
likely that there will be changes in libstdc++ that don't preserve the
libstdc++ ABI.  However, on platforms that support symbol versioning
(e.g. Linux), symbol versioning could in theory be used to reduce the
impact of such changes.  Note that symbol versioning is only a partial
solution; it can keep existing *executables* working with new versions
of libstdc++.so, but there may be problems with existing .so files,
.a files, or .o files that reference libstdc++.so.

(Why do you ask?)

P.S. I have a question of my own regarding symbol versioning.  Suppose I
have a C++ library `libfoo.so' that references libstdc++.so, and an
application `bar' that references both libfoo.so and libstdc++.so, and
suppose an ABI-breaking change is made to libstdc++.  A new version of
libstdc++ is installed; this has both the symbols for the new libstdc++
ABI, and symbols compatible with the old libstdc++ ABI, marked with the
old version number.  So `bar' continues to work.  Now, I try to compile
an application `baz' that references both libfoo.so and libstdc++.so.
`baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
to a version that uses the new version of the libstdc++.so ABI.  But that
would break `bar', wouldn't it?  (Or am I just hopelessly confused about
how symbol versioning works?)  Is there any simple way I can make `baz'
work without needing to recompile `bar', and without needing to bump
the libstdc++.so major version number?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: gcc 3.3

[Jim Wilson]

>The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
>with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
>ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
>that all the ABI bugs have now been caught, but no-one knows for sure.

PR 7442 submitted today reports more C++ ABI issues.  This one covers problems
with the cxxabi.h file.

There are also known back end problems that haven't been fixed yet.  We
use .init/.fini sections instead of .init_array/.fini_array sections for
static constructors/destructors.  We use .gnu.linkonce sections instead
of ELF COMDAT for template instantiation.  These should be fixable without
breaking backwards compatibility in theory, but we haven't tried yet.

I think we will continue to find C++ ABI bugs for a while.  There hasn't been
any attempt to verify the implementation against the specification.  I don't
think we should claim a stable C++ ABI until it is possible to link C++ code
compiled by gcc with C++ code compiled by other compilers, because only then
will we be able to test it.

Jim

Re: gcc 3.3

[Mark Mitchell]

--On Tuesday, July 30, 2002 07:16:55 PM -0400 Jim Wilson 
<wilson@redhat.com> wrote:

>> The hope is that yes, C++ compiled with gcc 3.3 will be binary compatible
>> with 3.2.  However, there's no guarantees; if gcc 3.2 turns out to have
>> ABI bugs, like 3.1 did, then they will need to be fixed.  The hope is
>> that all the ABI bugs have now been caught, but no-one knows for sure.
>
> PR 7442 submitted today reports more C++ ABI issues.  This one covers
> problems with the cxxabi.h file.

This is a library ABI issue, but not a compiler ABI issue.  (Just so that
everyone understands that.)  And, it's not even clear to me that the ABI
committee meant the names of those fields to be normative.  On the other
hand, we may as well make 'em match.

> I think we will continue to find C++ ABI bugs for a while.  There hasn't
> been any attempt to verify the implementation against the specification.

I keep dropping hints that something might happen here...

I agree with the thrust of your point, though.

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

Re: gcc 3.3

[Nathan Sidwell]

Mark Mitchell wrote:

> > PR 7442 submitted today reports more C++ ABI issues.  This one covers
> > problems with the cxxabi.h file.
> 
> This is a library ABI issue, but not a compiler ABI issue.  (Just so that
> everyone understands that.)  And, it's not even clear to me that the ABI
> committee meant the names of those fields to be normative.  On the other
No I don't think we meant them to be so. And it is certainly permissible
for an implementation to use different (virtual) member functions to
implement the catch & dynamic cast machinery. So (a) the vtables
must only be emitted by the compiler building the runtime, and (b)
a user cannot derived from those classes.


nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: gcc 3.3

[H. J. Lu]

On Wed, Jul 31, 2002 at 07:41:09AM +1000, Fergus Henderson wrote:
> 
> P.S. I have a question of my own regarding symbol versioning.  Suppose I
> have a C++ library `libfoo.so' that references libstdc++.so, and an
> application `bar' that references both libfoo.so and libstdc++.so, and
> suppose an ABI-breaking change is made to libstdc++.  A new version of
> libstdc++ is installed; this has both the symbols for the new libstdc++
> ABI, and symbols compatible with the old libstdc++ ABI, marked with the
> old version number.  So `bar' continues to work.  Now, I try to compile
> an application `baz' that references both libfoo.so and libstdc++.so.
> `baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
> to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
> to a version that uses the new version of the libstdc++.so ABI.  But that
> would break `bar', wouldn't it?  (Or am I just hopelessly confused about

Why will the new libfoo.so break bar if it is binary compatible with
the old libfoo.so?


H.J.

Re: gcc 3.3

[Fergus Henderson]

On 30-Jul-2002, H. J. Lu <hjl@lucon.org> wrote:
> On Wed, Jul 31, 2002 at 07:41:09AM +1000, Fergus Henderson wrote:
> > 
> > P.S. I have a question of my own regarding symbol versioning.  Suppose I
> > have a C++ library `libfoo.so' that references libstdc++.so, and an
> > application `bar' that references both libfoo.so and libstdc++.so, and
> > suppose an ABI-breaking change is made to libstdc++.  A new version of
> > libstdc++ is installed; this has both the symbols for the new libstdc++
> > ABI, and symbols compatible with the old libstdc++ ABI, marked with the
> > old version number.  So `bar' continues to work.  Now, I try to compile
> > an application `baz' that references both libfoo.so and libstdc++.so.
> > `baz' uses the new version of the libstdc++.so ABI, but libfoo.so refers
> > to the old version.  To make `baz' work, I'd need to upgrade libfoo.so
> > to a version that uses the new version of the libstdc++.so ABI.  But that
> > would break `bar', wouldn't it?  (Or am I just hopelessly confused about
> 
> Why will the new libfoo.so break bar if it is binary compatible with
> the old libfoo.so?

It's not guaranteed to be binary compatible with the old libfoo.so.
The source for libfoo has not changed.
However, libfoo may have dependencies on libstdc++
that mean that libfoo's ABI changes if/when libstdc++'s ABI changes
and libfoo is recompiled with the new libstdc++.

For example, libfoo's interface may refer to types defined in libstdc++.
If the size of those types changes, then libfoo's ABI will change.

Even if libfoo's interface doesn't refer to any types defined in
libstdc++, there can still be problems.
The new libfoo.so refers to the new version of the libstdc++.so ABI.
But bar refers to the old version of the libstdc++.so ABI.
It may not be possible to combine the two in a single process.
For static objects whose size or layout has changed in incompatible ways,
it is not possible for both libfoo.so and bar to refer to the same object.

I guess things will work OK if you bump the major version number
on libfoo.so every time you compile it with a new version of libstdc++.
Then you can keep both the old and new versions of libfoo.so;
bar will continue to link with the old version, while baz
can link with the new version.

However, that approach will require either keeping around several
different versions of libfoo.so, or recompiling applications (such as bar)
that refer to it.  Furthermore, it means that library developers
are required to keep track of exactly which version of libstdc++
their binary libraries reference, so that they know to bump the major
version number when it changes.  They need to be aware that their
own ABI can change when they install a new version of libstdc++
which differs only in minor version number from the previous one.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: gcc 3.3

[H. J. Lu]

On Wed, Jul 31, 2002 at 12:28:57PM +1000, Fergus Henderson wrote:
> > 
> > Why will the new libfoo.so break bar if it is binary compatible with
> > the old libfoo.so?
> 
> It's not guaranteed to be binary compatible with the old libfoo.so.
> The source for libfoo has not changed.
> However, libfoo may have dependencies on libstdc++
> that mean that libfoo's ABI changes if/when libstdc++'s ABI changes
> and libfoo is recompiled with the new libstdc++.
> 

Is this any different from glibc? That is not a new problem. You just
have to deal with it. Sometimes, it may not be an easy thing to do. 


H.J.

Re: gcc 3.3

[Joe Buck]

> I didn't see this addressed on the site...will 3.3 be binary compatible 
> with 3.2 (unlike 3.2>3.1)?

The 3.2/3.1 binary compatibilities affect only C++ code.

The intent is for 3.3 to be binary-compatible with 3.2 for C++ code.  As
for libstdc++, the story might be different depending on whether your
platform supports symbol versioning, which is the approach being used to
allow for development while keeping things binary-compatible.  Perhaps
the libstdc++ developers can say more on that one.

Of course there are no warranties for any of this.

Re: gcc 3.3

[Phil Edwards]

On Wed, Jul 31, 2002 at 09:39:08AM -0700, Joe Buck wrote:
> The intent is for 3.3 to be binary-compatible with 3.2 for C++ code.  As
> for libstdc++, the story might be different depending on whether your
> platform supports symbol versioning,

and uses a recent GNU linker (others could be supported, but nobody has
contributed such support at present),

> which is the approach being used to
> allow for development while keeping things binary-compatible.  Perhaps
> the libstdc++ developers can say more on that one.

We also have an open question about the details of symbol versioning:

    http://gcc.gnu.org/ml/libstdc++/2002-07/msg00177.html


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams