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

[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

[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: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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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.