Re: Getting 3.3 out the door

Re: Getting 3.3 out the door

[Wolfgang Bangerth]

Can I lobby a little for c++/9393? I only rediscovered this these days, so 
I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
have priority "high" until very recently). It's
- a problem that one cannot work around
- generates code that cannot be linked
- violates the C++ standard
- a regression against 2.95
- breaks my application and prevents Brad from running it on his system :-)

(In short: members of anonymous namespaces only get mangled names that
depend on the file name, nothing else. If you compile the same file twice
with different flags, then link them together, you'll get linker errors 
about duplicate symbols for all members of anonymous namespaces in this 
file.)

W.

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

Re: Getting 3.3 out the door

[Wolfgang Bangerth]

> > Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> 
> We've already fought about this one. :-)  See my "Release-Note" there.

Ah, sorry about that. I just missed it. I'll downgrade the priority then 
again.


> This one can't be fixed in the 3.3 time frame, I don't think.

Too bad. Do I get from your explanation in the PR, that the EDG frontend
basically computed a hash from its present compiler state to get a name
for anonymous namespaces? Also, why do these functions get external 
linkage at all?

W.

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

Re: Getting 3.3 out the door

[Mark Mitchell]

On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> 
> Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
> have priority "high" until very recently). It's
> - a problem that one cannot work around
> - generates code that cannot be linked
> - violates the C++ standard
> - a regression against 2.95
> - breaks my application and prevents Brad from running it on his system :-)

We've already fought about this one. :-)  See my "Release-Note" there.

This one can't be fixed in the 3.3 time frame, I don't think.

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

Re: Getting 3.3 out the door

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 03:16:18PM -0700, Mark Mitchell wrote:
> On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> > 
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> > I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
> > have priority "high" until very recently). It's
> > - a problem that one cannot work around
> > - generates code that cannot be linked
> > - violates the C++ standard
> > - a regression against 2.95
> > - breaks my application and prevents Brad from running it on his system :-)
> 
> We've already fought about this one. :-)  See my "Release-Note" there.
> 
> This one can't be fixed in the 3.3 time frame, I don't think.

In the interim, couldn't we do something based on a hash of the command
line options, or so?  It's not perfect, but it is an improvement; and
there are no binary compatibility issues in choosing the mangled names
for anonymous namespaces, so an interim solution should be acceptable.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Getting 3.3 out the door

[Joe Buck]

On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> > 
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> > I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
> > have priority "high" until very recently). It's
> > - a problem that one cannot work around
> > - generates code that cannot be linked
> > - violates the C++ standard
> > - a regression against 2.95
> > - breaks my application and prevents Brad from running it on his system :-)

On Thu, Apr 10, 2003 at 03:16:18PM -0700, Mark Mitchell wrote:
> We've already fought about this one. :-)  See my "Release-Note" there.
> 
> This one can't be fixed in the 3.3 time frame, I don't think.

There is a relatively simple, though controversial, "fix": treat
anonymous namespace names as static.  There are some problems with
that solution, for example, the question of what happens if there's
a template defined on a type declared in the anonymous namespace, as
well as a few other oddities like that, but the committee intended
anonymous namespaces to replace "static", so in the majority of cases
it should be possible to handle it in the same way.

Even in cases where we don't have a link failure as in 9393, we are
degrading link performance for users that listen to the committee and
replace file-static by anonymous namespace usage.

Possibly some compromise based on filtering could be acceptable: if
there's no reason why an anonymous namespace symbol must be exported,
don't export it, but do export it in cases where this is needed.  This
would not completely eliminate the issue, but it would reduce the damage.
That is, only generate anonymous namespace symbols as global in cases
where they are used in a way that requires global-ness.

Re: Getting 3.3 out the door

[Mark Mitchell]

> > This one can't be fixed in the 3.3 time frame, I don't think.
> 
> Too bad. Do I get from your explanation in the PR, that the EDG frontend
> basically computed a hash from its present compiler state to get a name
> for anonymous namespaces? Also, why do these functions get external 
> linkage at all?

Yes, you can think of it as a hash of its present state.

These functions get external linkage because the C++ standard says they
do.  On the other hand, I've never been able to figure out whether a
conforming program could actually *tell*.  Adding "export" into the mix
makes it more complicated; now an export template defined in that file
but instantiated somewhere else can see the members of the anonymous
namespace.

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

Re: Getting 3.3 out the door

[Joe Buck]

On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> These functions get external linkage because the C++ standard says they
> do.  On the other hand, I've never been able to figure out whether a
> conforming program could actually *tell*.  Adding "export" into the mix
> makes it more complicated; now an export template defined in that file
> but instantiated somewhere else can see the members of the anonymous
> namespace.

Exactly!  In the majority of cases there is no conforming program that
can tell the difference between file-static and anonymous namespace.
It appears that exported templates can tell, and there may be a couple
of other similar cases.

My suggestion is to avoid emitting globals for anonymous namespace members
until the end of the unit, at which point any that must be generated are
generated.  Names are flagged as "must be generated" when a situation
like a use in an exported template occurs.  There may be others, but
I expect them to be rare.
 

Re: Getting 3.3 out the door

[Branko Čibej]

Joe Buck wrote:

>There is a relatively simple, though controversial, "fix": treat
>anonymous namespace names as static.  There are some problems with
>that solution, for example, the question of what happens if there's
>a template defined on a type declared in the anonymous namespace, as
>well as a few other oddities like that, but the committee intended
>anonymous namespaces to replace "static", so in the majority of cases
>it should be possible to handle it in the same way.
>

If I understand correctly, symbols that are defined in an anonymous
namespace can't be used from outside the compilation unit, regardless of
their linkage. If that's correct, then generating a UUID every time a
file is compiled, and using that for the namespace name (suitably
protected with leading underscores), would solve the problems, wouldn't
it? It doesn't matter if a later compile of the same file with the same
compiler options used a different namespace name, because things like
teimpate instantiations based on the anonymous-namespace types would be
regenerated anyway.



-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: Getting 3.3 out the door

[Mark Mitchell]

On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > These functions get external linkage because the C++ standard says they
> > do.  On the other hand, I've never been able to figure out whether a
> > conforming program could actually *tell*.  Adding "export" into the mix
> > makes it more complicated; now an export template defined in that file
> > but instantiated somewhere else can see the members of the anonymous
> > namespace.
> 
> Exactly!  In the majority of cases there is no conforming program that
> can tell the difference between file-static and anonymous namespace.
> It appears that exported templates can tell, and there may be a couple
> of other similar cases.
> 
> My suggestion is to avoid emitting globals for anonymous namespace members
> until the end of the unit, at which point any that must be generated are
> generated.  Names are flagged as "must be generated" when a situation
> like a use in an exported template occurs.  There may be others, but
> I expect them to be rare.

This is all a good idea, and I agree, but I don't think it's appropriate
for 3.3.  It's not a trivial change, and the C++ front end is fragile
with respect to emission order, due to the interplay between the varasm
routines and the front end.  You can also mess up things like
initialized constants and template instantiation if you're not careful.

Jan's worked on this for 3.4, and doing what you suggest there would
likely make sense.

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

Re: Getting 3.3 out the door

[Mark Mitchell]

On Thu, 2003-04-10 at 15:43, Branko Čibej wrote:
> Joe Buck wrote:
> 
> >There is a relatively simple, though controversial, "fix": treat
> >anonymous namespace names as static.  There are some problems with
> >that solution, for example, the question of what happens if there's
> >a template defined on a type declared in the anonymous namespace, as
> >well as a few other oddities like that, but the committee intended
> >anonymous namespaces to replace "static", so in the majority of cases
> >it should be possible to handle it in the same way.
> >
> 
> If I understand correctly, symbols that are defined in an anonymous
> namespace can't be used from outside the compilation unit, regardless of
> their linkage. If that's correct, then generating a UUID every time a
> file is compiled, and using that for the namespace name (suitably
> protected with leading underscores), would solve the problems, wouldn't
> it? It doesn't matter if a later compile of the same file with the same
> compiler options used a different namespace name, because things like
> teimpate instantiations based on the anonymous-namespace types would be
> regenerated anyway.

We've been here before. :-)

We used to randomize the names, which works nicely.

But some programs can use the anonymous namespace members from a place
that is very much like "outside the compilation unit".

Furthermore, non-deterministic compilation was considered a misfeature.

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

Re: Getting 3.3 out the door

[Branko Čibej]

Mark Mitchell wrote:

>On Thu, 2003-04-10 at 15:43, Branko ÄŒibej wrote:
>  
>
>>If I understand correctly, symbols that are defined in an anonymous
>>namespace can't be used from outside the compilation unit, regardless of
>>their linkage. If that's correct, then generating a UUID every time a
>>file is compiled, and using that for the namespace name (suitably
>>protected with leading underscores), would solve the problems, wouldn't
>>it? It doesn't matter if a later compile of the same file with the same
>>compiler options used a different namespace name, because things like
>>teimpate instantiations based on the anonymous-namespace types would be
>>regenerated anyway.
>>    
>>
>
>We've been here before. :-)
>

Ah. I might have known. :-)

>We used to randomize the names, which works nicely.
>
>But some programs can use the anonymous namespace members from a place
>that is very much like "outside the compilation unit".
>

They can? Hmm.
/me tries to think of examples

>Furthermore, non-deterministic compilation was considered a misfeature.
>  
>

-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: Getting 3.3 out the door

[Geoff Keating]

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:

> Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
> have priority "high" until very recently). It's
> - a problem that one cannot work around
> - generates code that cannot be linked
> - violates the C++ standard
> - a regression against 2.95
> - breaks my application and prevents Brad from running it on his system :-)
> 
> (In short: members of anonymous namespaces only get mangled names that
> depend on the file name, nothing else. If you compile the same file twice
> with different flags, then link them together, you'll get linker errors 
> about duplicate symbols for all members of anonymous namespaces in this 
> file.)

This appears to be an intentional change, but with no justification or
discussion (other than "this fixes my bootstrap"), see

<http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00496.html>

It's clearly wrong because of exactly this case.  If people want
reproducible builds, we should have a flag which suppresses the
randomness.  I'll work on a quick patch.

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

Re: Getting 3.3 out the door

[Joe Buck]

On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > My suggestion is to avoid emitting globals for anonymous namespace members
> > until the end of the unit, at which point any that must be generated are
> > generated.  Names are flagged as "must be generated" when a situation
> > like a use in an exported template occurs.  There may be others, but
> > I expect them to be rare.

On Thu, Apr 10, 2003 at 03:45:23PM -0700, Mark Mitchell wrote:
> This is all a good idea, and I agree, but I don't think it's appropriate
> for 3.3.

It would be OK with me to postpone it to 3.4.

Re: Getting 3.3 out the door

[Jan Hubicka]

> On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > > These functions get external linkage because the C++ standard says they
> > > do.  On the other hand, I've never been able to figure out whether a
> > > conforming program could actually *tell*.  Adding "export" into the mix
> > > makes it more complicated; now an export template defined in that file
> > > but instantiated somewhere else can see the members of the anonymous
> > > namespace.
> > 
> > Exactly!  In the majority of cases there is no conforming program that
> > can tell the difference between file-static and anonymous namespace.
> > It appears that exported templates can tell, and there may be a couple
> > of other similar cases.
> > 
> > My suggestion is to avoid emitting globals for anonymous namespace members
> > until the end of the unit, at which point any that must be generated are
> > generated.  Names are flagged as "must be generated" when a situation
> > like a use in an exported template occurs.  There may be others, but
> > I expect them to be rare.
> 
> This is all a good idea, and I agree, but I don't think it's appropriate
> for 3.3.  It's not a trivial change, and the C++ front end is fragile
> with respect to emission order, due to the interplay between the varasm
> routines and the front end.  You can also mess up things like
> initialized constants and template instantiation if you're not careful.
> 
> Jan's worked on this for 3.4, and doing what you suggest there would
> likely make sense.

What do you mean?  The unit-at-a-time bits?
I pushed these that I can get across majority of C++ testsuite, however
still some constructors and such appears to be missed in the resulting
binaries.  I will try to look into this over weekend and send a
questions if I fail to track this down.

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

Re: Getting 3.3 out the door

[Mark Mitchell]

On Thu, 2003-04-10 at 16:41, Jan Hubicka wrote:
> > On Thu, 2003-04-10 at 15:41, Joe Buck wrote:
> > > On Thu, Apr 10, 2003 at 03:33:03PM -0700, Mark Mitchell wrote:
> > > > These functions get external linkage because the C++ standard says they
> > > > do.  On the other hand, I've never been able to figure out whether a
> > > > conforming program could actually *tell*.  Adding "export" into the mix
> > > > makes it more complicated; now an export template defined in that file
> > > > but instantiated somewhere else can see the members of the anonymous
> > > > namespace.
> > > 
> > > Exactly!  In the majority of cases there is no conforming program that
> > > can tell the difference between file-static and anonymous namespace.
> > > It appears that exported templates can tell, and there may be a couple
> > > of other similar cases.
> > > 
> > > My suggestion is to avoid emitting globals for anonymous namespace members
> > > until the end of the unit, at which point any that must be generated are
> > > generated.  Names are flagged as "must be generated" when a situation
> > > like a use in an exported template occurs.  There may be others, but
> > > I expect them to be rare.
> > 
> > This is all a good idea, and I agree, but I don't think it's appropriate
> > for 3.3.  It's not a trivial change, and the C++ front end is fragile
> > with respect to emission order, due to the interplay between the varasm
> > routines and the front end.  You can also mess up things like
> > initialized constants and template instantiation if you're not careful.
> > 
> > Jan's worked on this for 3.4, and doing what you suggest there would
> > likely make sense.
> 
> What do you mean?  The unit-at-a-time bits?

Right.  That's what Joe's talking about, but by a different name.  If we
had unit-at-a-time, doing the fix that Joe wants would be easy(ish).

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

Getting 3.3 out the door

[Andrew Haley]

Nathanael Nerode writes:
 > 
 > * Show-stoppers: must be fixed before release, regardless of difficulty *
 > 
 > Wrong code bugs:
 > 8866 Bug in switch statement code generation

Is anyone working on this one?

Andrew.

Re: Getting 3.3 out the door

[Svein E. Seldal]

Nathanael Nerode wrote:
> Compile time issues:

PR/10338 is also a problem for Cygwin.


Can someone else running Cygwin confirm/reject this error? If you do 
test it, please try to upgrade to the latest version Cygwin. I wonder if 
  that is causing the trouble.

If it turns out to be Cygwin implematation error, who is responsible to 
fix it? I mean, in the end the users/customers will not be able to 
compile gcc, regardless of the error's originator. Either gcc needs a 
workaround or the cygwin must be fixed. Anyone with any ideas?


Svein

RE: Getting 3.3 out the door

[Kean Johnston]

I am also just about done with reviving the port to OpenServer.
I am working my way through the test case failures and trying
to fix them before submitting patches, but I am pretty close.
I wouldn't hold the release up for it though but it would be
nice to knwow hat kind of time frame you're talking about so
I have something to shoot for. If I don't get all this in for
3.3, maybe for 3.3.1 or 3.4, but 3.3 would be nice.

Kean

Re: Getting 3.3 out the door

[Nathanael Nerode]

>> (Some of these might be more critical than I'm guessing.)
>> 9738 (mingw/cygwin)
>> 9929 (mingw/cygwin)
>> 10148 (mingw/cygwin)
>> 7910 (mingw/cygwin)
>> 8378 (mingw/cygwin)

>Except for 9929 (which is not mingw/cygwin) all those reports seems to
>involve __attribute__((dllimport))

Yaargh, how did that get on that list?  My error.

Re: Getting 3.3 out the door

[Mark Mitchell]

> 	Developing an effective solution to this bug report is proving
> very difficult.  It appeared when David Miller removed SEQUENCE rtl,
> exposing some sort of latent bug.  Pessimizing all frame pointer
> references will prevent GCC from achieving its performance requirements
> necessary for the release to proceed.

We're going to have to:

(a) Release with the pessimistic version, maybe under #ifdef
__powerpc__.

(b) Live with the codegen bug.

(c) Fix the bug.

(d) Make no more GCC releases ever.

I'm not very happy with (d).

I think that, due to the fact you site (like that there is no easy patch
to revert), we're going to have to choose between (a), (b), and (c).

Since (c) is a non-trivial choice (someone has to do work and/or spend
money), I don't think we can just say "well, we'll fix it."

David, I suggest that you indicate whether (a) or (b) is better from
your point of view, as a fallback.  At the same time, I'd suggest you
continue working on (c).

Thanks,

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

Re: Getting 3.3 out the door

[Oscar Fuentes]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> Here's a (somewhat ill-informed) attempt to triage the high-priority 
> bugs which are regressions in 3.3.  I've been rather more aggressive
> than some people might be; I want to get 3.3 out the door so we can stop
> worrying about 3.2 maintenance so much.

[snip]

> Specific to secondary platform:
> (Some of these might be more critical than I'm guessing.)
> 9738 (mingw/cygwin)
> 9929 (mingw/cygwin)
> 10148 (mingw/cygwin)
> 7910 (mingw/cygwin)
> 8378 (mingw/cygwin)

Except for 9929 (which is not mingw/cygwin) all those reports seems to
involve __attribute__((dllimport))

[snip]

-- 
Oscar

Re: Getting 3.3 out the door

[David Edelsohn]

>>>>> Nathanael Nerode writes:

Nathanael> * Show-stoppers: must be fixed before release, regardless of difficulty *

Nathanael> Wrong code bugs:
Nathanael> 9745 alias problem during loop pass (powerpc)

	Developing an effective solution to this bug report is proving
very difficult.  It appeared when David Miller removed SEQUENCE rtl,
exposing some sort of latent bug.  Pessimizing all frame pointer
references will prevent GCC from achieving its performance requirements
necessary for the release to proceed.

	Reverting the SEQUENCE rtl removal patch is impossible.  Teaching
GCC's current alias analysis infrastructure how to handle a non-fixed
frame pointer is proving equally difficult.

	We might be able to re-introduce the implicit restriction imposed
by SEQUENCE which allowed the specific testcase to work, but an alias
analysis flaw will remain.

David

Re: Getting 3.3 out the door

[Peter Barada]

>* Show-stoppers: must be fixed before release, regardless of difficulty *
>
>Wrong code bugs:
>8866 Bug in switch statement code generation
>9745 alias problem during loop pass (powerpc)
>10021 alias problem during loop pass (m68k)

What about target/8309?

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Getting 3.3 out the door

[Nathanael Nerode]

Here's a (somewhat ill-informed) attempt to triage the high-priority 
bugs which are regressions in 3.3.  I've been rather more aggressive
than some people might be; I want to get 3.3 out the door so we can stop
worrying about 3.2 maintenance so much.

I'd start checking out the other release criteria, but with the 
showstoppers still outstanding, I figure maybe it's worth waiting until 
they're fixed.

* Show-stoppers: must be fixed before release, regardless of difficulty *

Wrong code bugs:
8866 Bug in switch statement code generation
9745 alias problem during loop pass (powerpc)
10021 alias problem during loop pass (m68k)

ICE-on-legal without clear workaround:
6860

* Probably easy enough that they should be fixed *

Wrong code bugs:
10339 misoptimization (non-critical optimization can just be removed)

Fix submitted:
10308
10336

* Not sufficiently analyzed *
10300 (weird situation -- does it affect more normal situations?)
9302 (does this affect 3.3 or not?)
10206 (not confirmed yet)
10315 (not confirmed yet)
8306 (is the fix easy to backport?)
10353 (miscellaneous java failures.  Status? Importance?)
8963 (is it even a bug?)
10235 (not confirmed)

Compile time issues:
8361
10196
I suspect these are sufficiently fixed for 3.3, but they should actually 
be tested against the release criteria (no more than 15% compile time 
increase over GCC 2.95.3).

* Probably not worth holding up release *

Specific to platforms neither primary nor secondary:
9772 (d30v-elf)
9594 (sh-elf)
10110 (mipsel-linux, ada specific)
10201 (IA-64)
10202 (IA-64)

Specific to secondary platform:
(Some of these might be more critical than I'm guessing.)
9738 (mingw/cygwin)
9929 (mingw/cygwin)
10148 (mingw/cygwin)
7910 (mingw/cygwin)
8378 (mingw/cygwin)

Fix is probably too hard:
7817 (doc bug)
9393 (anonymous namespaces and compiling same file twice)
9929 (amazing morphing spill-finding bug)
10282 (amazing moprhing spill-finding bug)
4672 (template bug, broken in entire 3.x series)

Warning misbehaviors:
10345
10180
10147

Straightforward workaround available:
7875 Function overloading dropped for temp object from ctor
9812 (ICE at -O2 & above only)
9786 (ICE with specific optimizations only)
9864 (ICE with FORTRAN optimization with DWARF2 debugging only)
8856 (accepts really wacky illegal code)

ICE on illegal:
8803
9181
8300