Re: GCC 3.5 Status (2004-08-29)

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I notice that the, uh, "project" to get Ada bootstrapping (Kenner,
    when can we expect this?) is not listed.  These changes will
    presumably be accepted in stage 3?

Because it's not a "project" in the sense of new development, but rather
bugs that Ada triggers in middle-end code.   Fixing bugs is Stage 3 work.
So the timing of the Ada work is not relevent to entering Stage 3.

    However, I'm beginning to worry that Ada is going to delay the release
    of GCC 3.5 substantially if it's not bootstrapping soon, because the
    long period without Ada bootstrapping is likely to lead to bug
    discoveries when Ada is revived from the dead.

Well it was bootstrapping on and off but indeed various changes have broken
it for about two weeks.  Part of the reason for the long period was that I
was in Europe for a meeting for about a week.

In any event, as of yesterday afternoon, I have it bootstrapping in my tree.
It should be bootstrapping again in the GCC CVS in a day or so.  It'll be
more work to get it ACATS clean because some of the kludges I used to work
around bugs will need to be converted into the proper fix.

    Is Ada functioning a requirement for the release?  If so it seems a
    moderately bad idea to go into stage 3 with it totally busted.

The answer to the first question has always been "no".  But in practice,
my expectation is that it will work fine on the release.

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> >    Is Ada functioning a requirement for the release?  If so it seems a
> >    moderately bad idea to go into stage 3 with it totally busted.
> 
> The answer to the first question has always been "no".  But in practice,
> my expectation is that it will work fine on the release.

We had a barely working Ada compiler in 3.3 (fortunately enough for
bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
on x86 and x86_64 at -O2.

I believe it's reasonable now to make it a requirement that Ada works in
future GCC releases, at least on x86 and x86_64 with no regression.

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> > >    Is Ada functioning a requirement for the release?  If so it seems a
> > >    moderately bad idea to go into stage 3 with it totally busted.
> > 
> > The answer to the first question has always been "no".  But in practice,
> > my expectation is that it will work fine on the release.
> 
> We had a barely working Ada compiler in 3.3 (fortunately enough for
> bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass

Well, fully working on x86, not working in 3.4 on 64-bit architectures
and not working on ppc32 (while it worked in 3.3 on all of them).

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > on x86 and x86_64 at -O2.
>
> Well, fully working on x86, not working in 3.4 on 64-bit architectures
> and not working on ppc32 (while it worked in 3.3 on all of them).

3.3 did not have ACATS so working = bootstrap, which doesn't
mean much for end user (I know of no one successfully using Ada with FSF
3.3 except for bootstraping 3.4).

3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

(Also I believe s390 and s390x results were quite good before tree-ssa)

But back to the point, is not having *all* architectures perfectly
working for a language a reason to allow breaking of previously working
architectures? 

Is the requirement for not release GCC with broken Ada on x86 and x86_64
too strong?

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 08:01:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> > On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > > on x86 and x86_64 at -O2.
> >
> > Well, fully working on x86, not working in 3.4 on 64-bit architectures
> > and not working on ppc32 (while it worked in 3.3 on all of them).
> 
> 3.3 did not have ACATS so working = bootstrap, which doesn't
> mean much for end user (I know of no one successfully using Ada with FSF
> 3.3 except for bootstraping 3.4).
> 
> 3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

It bootstraps for me only if I use 3.3 as a bootstrap compiler,
not when using 3.4 as a bootstrap compiler, see
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
(this happened on ia64 and x86-64 at least).

On ppc32, the problem is
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 18:24, Jakub Jelinek wrote:
> It bootstraps for me only if I use 3.3 as a bootstrap compiler,
> not when using 3.4 as a bootstrap compiler, see
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
> (this happened on ia64 and x86-64 at least).

I did not notice this one, the attached patch "cures"
the problem on my x86_64 box using 3.4.1 to bootstrap
(at the total cost of 10-15 seconds of rebuilding various things).

I'm not sure if I'm just working around -O2 code generation
problems in 3.4.1 or doing something more "correct"
with respect to the bootstrap process.

Arnaud?

I'll do more testing shortly (x86_64 starting with 3.3 and x86 with 3.3
and 3.4).

> On ppc32, the problem is
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

Unfortunately I don't have access to this platform. May be Eric
as author of the patch that introduced the problem has an idea?

Laurent

--- Make-lang.in.orig   2004-08-30 21:13:02.824369585 +0200
+++ Make-lang.in        2004-08-30 21:22:13.595332552 +0200
@@ -988,27 +988,32 @@
 ada/treeprs.ads : ada/treeprs.adt ada/sinfo.ads ada/xtreeprs.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xtreeprs ; ./xtreeprs ../treeprs.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xtreeprs ; \
+        ./xtreeprs ../treeprs.ads )

 ada/einfo.h : ada/einfo.ads ada/einfo.adb ada/xeinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xeinfo ; ./xeinfo ../einfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xeinfo ; \
+        ./xeinfo ../einfo.h )

 ada/sinfo.h : ada/sinfo.ads ada/xsinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xsinfo ; ./xsinfo ../sinfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xsinfo ; \
+        ./xsinfo ../sinfo.h )

 ada/nmake.adb : ada/sinfo.ads ada/nmake.adt ada/xnmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -b ../nmake.adb )

 ada/nmake.ads :  ada/sinfo.ads ada/nmake.adt ada/xnmake.adb ada/nmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -s ../nmake.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -s ../nmake.ads )

 update-sources : ada/treeprs.ads ada/einfo.h ada/sinfo.h ada/nmake.adb \
        ada/nmake.ads

Re: GCC 3.5 Status (2004-08-29)

[Eric Botcazou]

> > On ppc32, the problem is
> > http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html
>
> Unfortunately I don't have access to this platform. May be Eric
> as author of the patch that introduced the problem has an idea?

Err... my patch can't have retroactively introduced a problem.

-- 
Eric Botcazou

Re: GCC 3.5 Status (2004-08-29)

[Arnaud Charlet]

> I'm not sure if I'm just working around -O2 code generation
> problems in 3.4.1 or doing something more "correct"
> with respect to the bootstrap process.
> 
> Arnaud?

Certainly looks like a work around to me, to avoid a codegen problem at
-O2 in the bootstrap compiler, since you're forcing recompilation of the same
run time files at a different optimization level.

That being said, if this change can make more people able to test Ada
that would be a good reason to put this change in, although I'd rather
only do a minimal change (e.g. only do a gnatmake -f -a on the first file to
be built, and not do a -f -a on others, since they should use the newly
compiled files anyway) with proper documentation on why this peculiar
change is done.

Arno

Re: GCC 3.5 Status (2004-08-29)

[Florian Weimer]

* Laurent GUERBY:

> Is the requirement for not release GCC with broken Ada on x86 and x86_64
> too strong?

When was the last successful bootstrap of mainline, with Ada enabled?

I understand that Ada is already in much better shape than we expected
it to be before the tree-ssa merge (and that's certainly good news!),
but I really doubt we should make a release criterion the quality of a
component that has received very little testing by the general GCC
community.

Ada policy (was: GCC 3.5 Status (2004-08-29))

[Laurent GUERBY]

On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
> I understand that Ada is already in much better shape than we expected
> it to be before the tree-ssa merge (and that's certainly good news!),
> but I really doubt we should make a release criterion the quality of a
> component that has received very little testing by the general GCC
> community.

I'm just talking about bootstrap, passing ACATS and no known regression
on two targets, not "quality" in general (whatever that means).

The scenario I want to avoid is that we first reach 100% ACATS pass on
the two targets (looks likely), then later a patch goes in that
introduces 20 ACATS regressions on those two targets and the patch is
not fixed or reverted following the usual rules for other components. 

Is that what you want for Ada now? If not, why not spell it out clearly
to avoid discussions with no time left later on? Also
if this rule is not set now, I see no reason for it to be set later
then, and that's not good news for the GNU Compiler _Collection_
Ada-wise.

Laurent

PS: I have tested and will test again at work our 500 KSLOC software
with FSF CVS.

Re: Ada policy

[Zack Weinberg]

Laurent GUERBY <laurent@guerby.net> writes:

> On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>> I understand that Ada is already in much better shape than we
>> expected it to be before the tree-ssa merge (and that's certainly
>> good news!), but I really doubt we should make a release criterion
>> the quality of a component that has received very little testing by
>> the general GCC community.
>
> I'm just talking about bootstrap, passing ACATS and no known
> regression on two targets, not "quality" in general (whatever that
> means).
>
> The scenario I want to avoid is that we first reach 100% ACATS pass on
> the two targets (looks likely), then later a patch goes in that
> introduces 20 ACATS regressions on those two targets and the patch is
> not fixed or reverted following the usual rules for other components.

The last time this came up, I posted a list of requirements which I
consider non-negotiable prerequisites for the community at large being
required to test Ada when they are not specifically working on it.
This list received no commentary whatsoever, and no progress has been
made toward meeting any of the requirements except the separate libada
(which seems to have stalled).

http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

zw

Re: Ada policy

[Richard Guenther]

Zack Weinberg wrote:
> Laurent GUERBY <laurent@guerby.net> writes:
> 
> 
>>On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>>
>>>I understand that Ada is already in much better shape than we
>>>expected it to be before the tree-ssa merge (and that's certainly
>>>good news!), but I really doubt we should make a release criterion
>>>the quality of a component that has received very little testing by
>>>the general GCC community.
>>
>>I'm just talking about bootstrap, passing ACATS and no known
>>regression on two targets, not "quality" in general (whatever that
>>means).
>>
>>The scenario I want to avoid is that we first reach 100% ACATS pass on
>>the two targets (looks likely), then later a patch goes in that
>>introduces 20 ACATS regressions on those two targets and the patch is
>>not fixed or reverted following the usual rules for other components.
> 
> 
> The last time this came up, I posted a list of requirements which I
> consider non-negotiable prerequisites for the community at large being
> required to test Ada when they are not specifically working on it.
> This list received no commentary whatsoever, and no progress has been
> made toward meeting any of the requirements except the separate libada
> (which seems to have stalled).
> 
> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

Maybe testing rules could be relaxed if we had a GENERIC/GIMPLE 
front-end to fed it testcases which cannot be constructed using C code. 
  That way testing of frontends different from C could be omitted, if 
not modifying them.

Richard.

Re: Ada policy

[Richard Henderson]

On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

For the record, I completely agree.


r~

Re: Ada policy

[Diego Novillo]

On Mon, 2004-08-30 at 16:57, Richard Henderson wrote:
> On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> > http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html
> 
> For the record, I completely agree.
> 
Likewise.


Diego.

Re: Ada policy

[Robert Dewar]

Richard Henderson wrote:
> On Mon, Aug 30, 2004 at 01:34:25PM -0700, Zack Weinberg wrote:
> 
>>http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html
> 
> 
> For the record, I completely agree.

Reading Zack's message:

> Second, the Ada maintainers have said in the past that they
> deliberately break source compatibility between releases (such that
> GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).

That's entirely wrong. Nothing is broken deliberately, and no one
ever said anything of the kind. What they did say is that it
is not always feasible to maintain what Zack would like:

> There must be
> guaranteed bidirectional source compatibility between all 3.x branches
> of GCC, such that it is possible to build any 3.x version of GNAT with
> any other 3.x version of GNAT.

Unfortunately there are occasionally cases where bugs cannot
be fixed without breaking this requirement. It's relatively
rare, and for some time now, GNAT has been able to be built
with a pretty significant variety of starting compilers,
though no one guarantees this to be the case (the only
guarantee is that it builds with the most recent release,
although in practice we have been using a much older
compiler internally for starting builds).

Note that this is particularly the case if the GCC community
decides to stick with 3.xx designations indefinitely.

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> Reading Zack's message:
>> Second, the Ada maintainers have said in the past that they
>> deliberately break source compatibility between releases (such that
>> GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>
> That's entirely wrong. Nothing is broken deliberately, and no one
> ever said anything of the kind.

I disagree; that *is*, in fact, what is said or at least strongly
implied by messages like
<http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:

# Right now, we are in a transitioning phase, since there is no GCC
# release yet with Ada support. We could even disable Ada by default,
# as there will be people building binary versions anyway. For future
# versions, there is a very clear base compiler that should be used,
# which is the previous FSF released version of GCC.

Note that that was in the context of a discussion of whether configure
should refuse to enable Ada if the "wrong" bootstrap compiler was
found.

More explicitly, <http://gcc.gnu.org/ml/gcc/2002-05/msg02458.html> -
which you wrote - says that

#> It would be nice if we could preserve bootstrap compatibility
#> farther back, but if there are major gains to maintainability from
#> raising the bar, fine.
#
# Well certainly we are not going to make incompatibilities for the
# sake of making incompatibilties. But there are always cases in every
# release where we preserve some kludge for maintainability.

and goes on to talk about how it'd be nice to use pragma Unreferenced,
but this breaks compatibility with the Ada compiler in GCC 3.[12].
And, grepping gcc/ada, I see that there are now many uses of pragma
Unreferenced - so building GNAT with GCC 3.(<3) has indeed been
deliberately broken.

Now, I say

>> There must be guaranteed bidirectional source compatibility between
>> all 3.x branches of GCC, such that it is possible to build any 3.x
>> version of GNAT with any other 3.x version of GNAT.

and I do still insist on that.  But that doesn't mean you can't use
pragma Unreferenced; it just has to be properly conditionalized so
that GCC 3.(<3) somehow sees pragma Warnings (Off) instead.

With regard to this statement

> Unfortunately there are occasionally cases where bugs cannot be
> fixed without breaking this requirement. It's relatively rare, and
> for some time now, GNAT has been able to be built with a pretty
> significant variety of starting compilers

I have some sympathy for a situation where version X of GNAT contained
invalid code which version Y (Y > X) correctly rejects; but when this
occurs while version X is a still-live release branch, patches should
go into version X to correct the bug.

When it's a case of version X contains a bug which causes it to
miscompile the code in version Y (again, Y > X) I have *no* sympathy.
We work around this kind of thing all the damn time in the parts of
the compiler that are written in C, and I see no reason why the Ada
parts should be any different.

I'd also add that personally, I consider my third requirement (patch
submission according to the same requirements binding on all other
contributors) to be much more important than the one you chose to
discuss.

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> Robert Dewar <dewar@gnat.com> writes:
> 
> 
>>Reading Zack's message:
>>
>>>Second, the Ada maintainers have said in the past that they
>>>deliberately break source compatibility between releases (such that
>>>GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>>
>>That's entirely wrong. Nothing is broken deliberately, and no one
>>ever said anything of the kind.
> 
> 
> I disagree; that *is*, in fact, what is said or at least strongly
> implied by messages like
> <http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:

No, it definitely is NOT said here. There is absolutely nothing
there about deliberately breaking source compatibility. I can't
imagine how you manage this strange reading.

> and goes on to talk about how it'd be nice to use pragma Unreferenced,
> but this breaks compatibility with the Ada compiler in GCC 3.[12].
> And, grepping gcc/ada, I see that there are now many uses of pragma
> Unreferenced - so building GNAT with GCC 3.(<3) has indeed been
> deliberately broken.\

Please don't talk about things you have not studied carefully.
We never use pragma Unreferenced in the compiler, or in the
run-time units used by the compiler. If we did so, our nightly
runs would break, since some of them start from quite early
versions of the compiler. We use pragma Unreferenced only in
the run-time, but this is always built with the newly built
compiler, so there is no issue there.

Just so things are clear, we start our nightly runs with several
different older versions of the compiler precisely to make sure
we retain as much compatibility with old versions as possible
for builds. Any impression that this kind of compatibility has
been recently broken at all, let alone deliberately, is based
on confusion and lack of understanding I am afraid.

> I have some sympathy for a situation where version X of GNAT contained
> invalid code which version Y (Y > X) correctly rejects; but when this
> occurs while version X is a still-live release branch, patches should
> go into version X to correct the bug.

I disagree with this, you don't want to discombobulate users using the
older version of the compiler, and in any case this is largely
unnecessary. You are really creating strawmen here. The current version
of Ada bootstraps with quite old versions of GNAT.

> I'd also add that personally, I consider my third requirement (patch
> submission according to the same requirements binding on all other
> contributors) to be much more important than the one you chose to
> discuss.

You must be missing some messages in this thread, since that has
most certainly been discussed by me and others.
> 
> zw

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> Zack Weinberg wrote:
>
>> Robert Dewar <dewar@gnat.com> writes:
>>
>>>Reading Zack's message:
>>>
>>>>Second, the Ada maintainers have said in the past that they
>>>>deliberately break source compatibility between releases (such that
>>>>GCC 3.x with Ada is only guaranteed to be buildable with GCC 3.(x-1)).
>>>
>>>That's entirely wrong. Nothing is broken deliberately, and no one
>>>ever said anything of the kind.
>> I disagree; that *is*, in fact, what is said or at least strongly
>> implied by messages like
>> <http://gcc.gnu.org/ml/gcc/2002-05/msg00086.html>:
>
> No, it definitely is NOT said here. There is absolutely nothing
> there about deliberately breaking source compatibility. I can't
> imagine how you manage this strange reading.

Whereas I cannot imagine how you manage to miss what is a clear
implication of the text of that message.

I'm willing to accept what you say now as a statement of a changed
policy, though.

> Just so things are clear, we start our nightly runs with several
> different older versions of the compiler precisely to make sure we
> retain as much compatibility with old versions as possible for
> builds.

I am very glad to hear this.  A further step forward would be to
state which older versions those are, what your policies are for
selecting those older versions, and when the set might change.

>> I'd also add that personally, I consider my third requirement
>> (patch submission according to the same requirements binding 
>> on all other contributors) to be much more important than the 
>> one you chose to discuss.
>
> You must be missing some messages in this thread, since that has
> most certainly been discussed by me and others.

Test cases has been discussed at length, but the other ways in which
ACT does not follow the patch submission requirements have not been
discussed at all.

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:
> Robert Dewar <dewar@gnat.com> writes:

> Whereas I cannot imagine how you manage to miss what is a clear
> implication of the text of that message.

The important point in the message is that it is critical that
the C and Ada compiler be consistent, that is still very much
the case (there may be isolated cases where this is not required
but such combinations are never tested by us).

> I'm willing to accept what you say now as a statement of a changed
> policy, though.

Well I am glad that you see a perceived change that you find
OK, there is in fact no change at all.

>>Just so things are clear, we start our nightly runs with several
>>different older versions of the compiler precisely to make sure we
>>retain as much compatibility with old versions as possible for
>>builds.
> 
> 
> I am very glad to hear this.

This has been the case for a long time

>  A further step forward would be to
> state which older versions those are, what your policies are for
> selecting those older versions, and when the set might change.

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:
> Zack Weinberg wrote:
>> Robert Dewar <dewar@gnat.com> writes:
>> Whereas I cannot imagine how you manage to miss what is a clear
>> implication of the text of that message.
>
> The important point in the message is that it is critical that
> the C and Ada compiler be consistent
[...]

That may be what you see as the important point in the message, but it
is by no means the only thing said in the message, let alone the only
implication of the message.

This discussion is about appearances as well as actuality.  Can you at
least agree that a reasonable person could reach my position?  That is,
maybe ACT has never actually broken using an older GCC to bootstrap
the Ada front end, but can you understand how I and others have come
to the conclusion that your policy was not to keep it working?

>> A further step forward would be to state which older versions those
>> are, what your policies are for selecting those older versions, and
>> when the set might change.

Please answer this question.

> You did not reply about your pragma Unreferenced misunderstanding.
> I trust you are clear on this issue, and your mistake here???

You responded to the pragma Unreferenced citation by stating that
pragma Unreferenced was not actually used in the compiler proper.
That is new information.  It was not in the message I cited.  Can you
understand how a reasonable person, working from the information in
that message, could have thought that the Ada maintainers planned to
introduce uses of pragma Unreferenced into the compiler proper?

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> This discussion is about appearances as well as actuality.  Can you at
> least agree that a reasonable person could reach my position? 

What? Your position that we said we intended to deliberately
break things? No, I don't see how anyone could reach that
conclusion. Sorry. If you are simply saying that the message
says we do not guarantee to boostrap with arbitrary old versions
of GNAT, yes, that's the case.

The interesting thing here is that we have virtually no reports
of people having difficulty in practice bootstrapping Ada on all
sorts of targets where the difficulty arises from this consideration.
Seems a bit of a tempest in a teapot to me.

Yes, there was the discussion of trying to use incompatible
versions with different exception handling. That's an unsolvable
case, or at least the solution would require a lot of recoding and
introduction of inefficiencies to no very good purpose.

> That is,
> maybe ACT has never actually broken using an older GCC to bootstrap
> the Ada front end, but can you understand how I and others have come
> to the conclusion that your policy was not to keep it working?

There is a BIG difference between your unjustified claim that
we deliberately break things, and our position that we try to
keep the bootstrap working with old versions of the compiler,
but do not guarantee to do so.

It is *certainly* not the case that any old arbitrary GNAT can be
used (there are dozens of versions stretching back over 13 years
after all!)

>>>A further step forward would be to state which older versions those
>>>are, what your policies are for selecting those older versions, and
>>>when the set might change.

> Please answer this question.

I will answer this later, I don't have this info at hand
right now. Basically the policy is to try to keep compatibility
to the greatest extent possible, but if it is necessary to fix
some bug in the compiler to break an old version, we may do so.
A possible case is when fixing a bug changes the compiler sources
in a way that aggravates some other bug in an earlier version of
the compiler, and no work around can be easily found. This is very
rare, but has happened at least once in the last decade.

>>You did not reply about your pragma Unreferenced misunderstanding.
>>I trust you are clear on this issue, and your mistake here???

> You responded to the pragma Unreferenced citation by stating that
> pragma Unreferenced was not actually used in the compiler proper.
> That is new information.  It was not in the message I cited.  Can you
> understand how a reasonable person, working from the information in
> that message, could have thought that the Ada maintainers planned to
> introduce uses of pragma Unreferenced into the compiler proper?

Possibly so, but I was reacting to your claim that you had examined
the sources and found deliberate violations of the rule, which is
quite wrong and represented a misunderstanding of the technical
situation. I suggest you review the way Ada is built so that you
can understand this point in more detail. Basically the point is
that the run time (*) and tools are always built with the newly
constructed compiler, so bootstrap path problems do not apply
to these components. When you scanned the compiler sources for
pragma Unreferenced, you found a long list of uses, but all in
the run time and tools. You then jumped to a conclusion that this
was proof of our deliberately breaking things. That was a bit
too rapid a jump :-)

(*) That's not quite complete, since some run-time components (see
makefile) are in fact used in the compiler, and these have to be
treated with special care, since they have to be compatible with
both the starting and ending versions of the compiler (this is
why we severely limit the set of run time units used).

Re: Ada policy

[Zack Weinberg]

Robert Dewar <dewar@gnat.com> writes:

> Zack Weinberg wrote:
>
>> This discussion is about appearances as well as actuality.  Can you at
>> least agree that a reasonable person could reach my position?
>
> What? Your position that we said we intended to deliberately break
> things? No, I don't see how anyone could reach that
> conclusion. Sorry.

Having thought about this a bit more, I can only defend a slightly
weaker assertion based on messages I can actually find in the mailing
list archives.  See my response to Kenner.  Can you agree that a
reasonable person could have reached *that* conclusion?

> The interesting thing here is that we have virtually no reports
> of people having difficulty in practice bootstrapping Ada on all
> sorts of targets where the difficulty arises from this consideration.
> Seems a bit of a tempest in a teapot to me.

That is a good sign...

> It is *certainly* not the case that any old arbitrary GNAT can be
> used (there are dozens of versions stretching back over 13 years
> after all!)

I continue to be disappointed that an arbitrary standard-conforming
Ada compiler cannot be used.

> Possibly so, but I was reacting to your claim that you had examined
> the sources and found deliberate violations of the rule, which is
> quite wrong and represented a misunderstanding of the technical
> situation. I suggest you review the way Ada is built so that you
> can understand this point in more detail.

Until such time as the distinction between the runtime and the
compiler proper is reflected in the organization of the source tree, I
cannot be bothered to figure out which is which.  This must sound
dreadfully lazy to you, but consider that from my point of view,
checking in a grab bag of patches once a week with no public review is
far lazier.  (You continue not to address this concern.)

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> Having thought about this a bit more, I can only defend a slightly
> weaker assertion based on messages I can actually find in the mailing
> list archives.  See my response to Kenner.  Can you agree that a
> reasonable person could have reached *that* conclusion?

Well quite a bit weaker actually :-) Saying that we were deliberately
breaking things seemed to be going a bit far!

The issue is a simple one. It is the extent of the guarantee that
it will be possible to bootstrap from previous versions. If you
imagine for a moment that the g++ front end were written entirely
in C++, I think you can see that it would not be quite so easy to
guarantee that it could be bootstrapped with any previous version
of g++. Of course everyone agrees that it is desirable to maintain
the broadest possible set of bootstrap paths (that's why the
accusation that we were deliberately breaking things rankled a
bit :-)

The question is whether you can guarantee that it will be possible
to bootstrap with all previous versions. Well of course you cannot
make that broad of a guarantee. So what you want to do is to balance
the conflicting goals here:

1. Provide a front end that is as efficient as possible, written
as clearly as possible.

2. Maintain general bootstrap paths

I think in practice we have made the right decisions here. The
only reported difficulty was when you (Zack) tried to use some
inconsistent versions of C and GNAT, and exceptions could not
be properly supported in that mixed environment.

>>The interesting thing here is that we have virtually no reports
>>of people having difficulty in practice bootstrapping Ada on all
>>sorts of targets where the difficulty arises from this consideration.
>>Seems a bit of a tempest in a teapot to me.
> 
> That is a good sign...
> 
>>It is *certainly* not the case that any old arbitrary GNAT can be
>>used (there are dozens of versions stretching back over 13 years
>>after all!)

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

That would be a very fierce restriction, resulting in considerable
inefficiencies, since it would mean that we could not take advantage
of any of the standard GNAT pragmas and attributes, which are used
extensively (many of these attributes and pragmas were in fact put
there for use by the compiler in the first place, e.g. pragma
No_Return, so that we can turn on full warnings).

The probability of someone wanting to bootstrap GNAT starting with
an expensive proprietary compiler seems vanishingly small, given
that GNAT is so widely available, and that it is fairly easy to
build cross compilers to go to new architectures. I don't think
there are cases anyway (unlike the situation with GCC) where you
have an environment with an Ada compiler which is not GNAT, and
GNAT is not available.

Yes, in the abstract, this goal sounds desirable, but the gains
would be minuscule and the cost high. If you don't agree, spend
a bit of time (well it might take *quite* a bit of time) looking
through the sources to see how we use GNAT attributes. Look for
example at the use of 'Unrestricted_Access. Yes, you can remove
these uses, but in almost all cases you will do real damage to
the readability of the code. The technical problem here is that
Ada severely restricts the passing of subprograms as parameters.
Why? Becuase some other now defunct Ada compiler could not easily
support reasonable semantics, and the vendor screamed murder at
the standards committee. So everyone using standard Ada is stuck
with annoying work arounds.

> Until such time as the distinction between the runtime and the
> compiler proper is reflected in the organization of the source tree, I
> cannot be bothered to figure out which is which.

That's fine, but be careful about basing deductions from this
position of lack of understanding of the distinction. In practice
there is no issue of making mistakes here, since if for example,
you incorrectly use pragma Unreferenced in the compiler proper,
the build will fail if you follow our style of using an early
version of the compiler for the bootstrap.

> This must sound
> dreadfully lazy to you, but consider that from my point of view,
> checking in a grab bag of patches once a week with no public review is
> far lazier.  (You continue not to address this concern.)

It's not a matter of being lazy, it is simply a matter of resources.
If we had millions of dollars in the bank, and could afford to have
one or two full time people dedicated to the submission of patches
in a more separated way. I am dubious about review, almost all these
patches require a pretty detailed knowledge of GNAT to understand.
But review is always welcome (we certainly would welcome more
input anywhere on GNAT, and yes, if we spent more effort on how the
patches were submitted, it might help, but I doubt it). The situation
with back end general gcc patches is of course different, and as you
know these often get substantially discussed.

So we (AdaCore) have three choices at the moment

1. Don't submit Ada patches at all
2. Submit them as we are doing now, keeping the tree up to date
3. Submit them broken down, fully documented, with tests, for review

Yes, 3 would be nice, but there just aren't the resources to do it.
As it is doing 2 represents a significant investment for us. We
certainly recognize that we get a lot back for that investment,
but it already strains what we can achieve, given that attention
to supported customers is always our number one priority (without
the supported customers, there would be no patches from us :-)

So, not ideal, but 2 seems better than 1 to us, and arguing
strongly for 3 is not going to make much difference unless
someone is willing to fund this activity (in the old days
perhaps the AJPO could have been approached, but I don't
see any source for such funding today).

Robert

Re: Ada policy

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| Zack Weinberg wrote:
| 
| > Having thought about this a bit more, I can only defend a slightly
| > weaker assertion based on messages I can actually find in the mailing
| > list archives.  See my response to Kenner.  Can you agree that a
| > reasonable person could have reached *that* conclusion?
| 
| Well quite a bit weaker actually :-) Saying that we were deliberately
| breaking things seemed to be going a bit far!
| 
| The issue is a simple one. It is the extent of the guarantee that
| it will be possible to bootstrap from previous versions. If you
| imagine for a moment that the g++ front end were written entirely
| in C++, I think you can see that it would not be quite so easy to
| guarantee that it could be bootstrapped with any previous version
| of g++.

Why imagining the case of g++ when you can take the actual case of
cc1, the C front-end? :-)

-- Gaby

Re: Ada policy

[Robert Dewar]

Here is the promised information on what we currently test in terms
of bootstrap paths. We use the following compilers on various
machines to start the bootstrap

3.13a1 (similar to 3.13p)
3.14a1 (similar to 3.14p)
3.15a1 (similar to 3.15p)
3.16a1
5.02a1 (GCC 3.2.x based)

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

Oh, and by the way, I hope this does not come as a drastic surprise
to you, but there are no standard-conforming Ada compilers, not 100%
conforming, since a single bug contradicts that status, and I have to
report that especially in the case of previous versions of GNAT, we
know of quite a few bugs :-)

(as a marketing phrase, we have sometimes used the tag line "there
is only one bug in GNAT", but I am afraid this is not strictly true.

The point is that working around bugs in all previous versions of
GNAT (not to mention bugs in all previous versions of all alledgedly
standard Ada compilers) would be somewhat infeasible. Again, suppose
that you were required to code the g++ front end in C++ subject to
the requirement that it compile correctly on all previous versions
of C++ from all vendors, including all versions of g++, well that
would be tricky :-)

I suppose you could just degrade to coding in C after all, but the
whole point of moving to C++ for the front end of g++ (which by the
way seems a perfectly reasonable step to me), would be to take
advantage of some of the important features of C++. Yes, discussion
would be needed (and some has gone on) on what subset would be
appropriate, and you can see the discussion ranges from quite
conservative (me for example) to much more liberal, but certainly
even if you take a very conservative position, you cannot expect
to be compatible with all previous versions of c++ compilers,
and I would not argue for using this as a criterion.

Certainly in the case of Ada and GNAT, we had lots of discussions
about the subset to be used for the compiler, and it is actually
fairly small (e.g. avoiding tasking, controlled types, tagged
types etc).

P.S. Once upon a time (actually I think it was in 1992),
GNAT was bootstrapped with another compiler (the Alsys
compiler on SunOS), but once that bootstrap was complete,
we only ever regarded bootstrapping with GNAT as the
criterion for moving forward.

Re: Ada policy

[Gabriel Dos Reis]

Robert Dewar <dewar@gnat.com> writes:

| The point is that working around bugs in all previous versions of
| GNAT (not to mention bugs in all previous versions of all alledgedly
| standard Ada compilers) would be somewhat infeasible. Again, suppose
| that you were required to code the g++ front end in C++ subject to
| the requirement that it compile correctly on all previous versions
| of C++ from all vendors, including all versions of g++, well that
| would be tricky :-)

I think you could reason on facts: the C front-end!

-- Gaby

Re: Ada policy

[Laurent GUERBY]

On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
> I think you could reason on facts: the C front-end!

I'd say not relevant, the Ada subset used by GNAT is
much more complex than C. Also as soon as bootstrap
was complete, GNAT code started using Ada 9x features
and there was no other Ada 9x compiler to help
with portability problems, which was clearly
not the situation for C.

Laurent

Re: Ada policy

[Zack Weinberg]

Laurent GUERBY <laurent@guerby.net> writes:

> On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
>> I think you could reason on facts: the C front-end!
>
> I'd say not relevant, the Ada subset used by GNAT is much more
> complex than C. Also as soon as bootstrap was complete, GNAT code
> started using Ada 9x features and there was no other Ada 9x compiler
> to help with portability problems, which was clearly not the
> situation for C.

And the C language seems to cater more for portability across
different implementations, too (with conditional compilation and the
like).

People seem to be reacting way out of proportion to this particular
observation.  There's good solid engineering reasons why you need GNAT
to build GNAT and I don't mean to second-guess that.  When I say I'm
disappointed, that's an abstract observation on the state of the Ada
language -- if it's not practical to write a large complex piece of
software such as a compiler in the language as standardized, then the
standard is less than useful, and that's disappointing.

[It's debatable whether it's practical to write a large complex piece
of software in the C language as ISO-standardized, but at least it's
possible to do so in the /de facto/ standard language.]

zw

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> People seem to be reacting way out of proportion to this particular
> observation.  There's good solid engineering reasons why you need GNAT
> to build GNAT and I don't mean to second-guess that.  When I say I'm
> disappointed, that's an abstract observation on the state of the Ada
> language -- if it's not practical to write a large complex piece of
> software such as a compiler in the language as standardized, then the
> standard is less than useful, and that's disappointing.

You have a strange way of jumping to extremely odd conclusions.

No one ever said that it is not practical to write a large complex
piece of software in standard Ada, and yet you conclude from our
quite deliberate choice here that this is not practical.

Of course it would be possible to write GNAT is standard Ada, but
since we decided long ago that the only requirement is that it
be able to compile itself, we might as well take advantage of the
many implementation dependent extra features in GNAT to improve
the quality and readabiity of the compiler.

> [It's debatable whether it's practical to write a large complex piece
> of software in the C language as ISO-standardized, but at least it's
> possible to do so in the /de facto/ standard language.]

It's FAR easier to write within the confines of the Ada standard than
the C standard since it is a much more flexible language. Just one
example, in C there is no way of precisely specifying the layout of
data, e.g. bit packed arrays. Zack, I have a feeling you don't know
Ada that well :-) :-)

Re: Ada policy

[Kai Henningsen]

dewar@gnat.com (Robert Dewar)  wrote on 31.08.04 in <4134C6C4.5090103@gnat.com>:

> You have a strange way of jumping to extremely odd conclusions.

Actually, Zack's conclusions seem far more logical to me than your  
arguments.

> No one ever said that it is not practical to write a large complex
> piece of software in standard Ada, and yet you conclude from our
> quite deliberate choice here that this is not practical.

You have a very strange way of switching from "we do it this way because  
the other way is not practical" to "we do this deliberately" to "how dare  
you say we do this deliberatly, it is the only practical way" to ... and  
so on.

MfG Kai

Re: Ada policy

[Robert Dewar]

It must be some other dewar who said

> "we do it this way because  
> the other way is not practical"

With respect to using portable Ada for large
projects. I said nothing of the kind. Yes of
course it would be practical to write GNAT in
portable Ada. It would also be practical to write
it in C++, but that does not mean it would be a
good idea in this case.

The bogus logic is to assume the following
syllogism which doesn't just have a divided
middle, it has no middle :-)


GNAT is written in non-portable Ada
GNAT is a large project
Therefore it is impractical to write large projects
  in portable Ada.

I have given lots of arguments and discussion to tell you
why we decided to use GNAT extensions in writing GNAT. Nowhere
among these arguments and discussions is any hint that one of
the reasons was that it was impractical to use portable Ada!

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> And the C language seems to cater more for portability across
> different implementations, too (with conditional compilation and the
> like).

Actually the point in Ada is that you don't need to "cater for
portability across different implementations", since it is perfectly
practical to write in completely standard portable Ada. In C, you
can't help running into portability issues because fundamental
definitions like the characteristics of int are implementation
dependent, and so you are forced to mess with conditional
compilation. When writing portable Ada, you would of course
completely avoid the use of the type Integer (which is what
corresponds to int), since you don't need to use these built
in integer types when you can define your own.

Re: Ada policy

[Scott Robert Ladd]

Robert Dewar wrote:
> Actually the point in Ada is that you don't need to "cater for
> portability across different implementations", since it is perfectly
> practical to write in completely standard portable Ada. In C, you
> can't help running into portability issues because fundamental
> definitions like the characteristics of int are implementation
> dependent, and so you are forced to mess with conditional
> compilation.

I am certainly not an Ada expert, so I can't comment on its abilities 
(or lack thereof).

However, I *can* comment on you understanding of C. Standard C (approved 
about five years ago) allows explicit declarations of integer sizes via 
the types in stdint.h. What you have encountered is either old code, or 
code written by people who are not aware of explicit type sizes.

This sort of "my language is better than your language" stuff is just 
plain silly, from any side of the issue.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Ada policy

[Robert Dewar]

Scott Robert Ladd wrote:

> However, I *can* comment on you understanding of C. Standard C (approved 
> about five years ago) allows explicit declarations of integer sizes via 
> the types in stdint.h. What you have encountered is either old code, or 
> code written by people who are not aware of explicit type sizes.

Hmm .. I admit I am not an expert in C99 but I thought that stdint.h only
required a very limited number of integer types, basically the powers of 2.
So for example, there is no equivalent of

    type R is range -2**23 .. 2**23-1;

which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
a 36 bit machine.

Well let me go look it up ...

Hmm .. http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html

seems to confirm my understanding, and actually that reference says it is
an extension of the C99 definition. What you would want is the type
int_least24_t, but that's not required to be defined. Am I
misunderstanding here?

> This sort of "my language is better than your language" stuff is just 
> plain silly, from any side of the issue.

Well I must say I was a bit surprised at the claim that it was arguable
whether large applications could be practically written sticking strictly
to ISO C (almost as surprising as Zack's claim that this was clearly
impractical for Ada :-) I also found the idea that the only way to
achieve portability is through use of conditional compilation to be
surprising (I doubt this is true).

Re: Ada policy

[Scott Robert Ladd]

Robert Dewar wrote:
> Hmm .. I admit I am not an expert in C99 but I thought that stdint.h only
> required a very limited number of integer types, basically the powers of 2.
> So for example, there is no equivalent of
> 
>    type R is range -2**23 .. 2**23-1;
> 
> which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
> a 36 bit machine.

Ah! No, that is *not* something that can be done in Standard C; I was 
unaware that Ada supported such a capability. See why I don't comment on 
Ada's capabilities? ;)

I understood that you were discussing portability (based on your focus 
on int), which is often a matter of making certain that type "X" has a 
compatible range across multiple platforms. Thus the stdint.h definitions.

That is, of course, assuming you have a Standard C compiler across your 
target platforms. :)

> Well I must say I was a bit surprised at the claim that it was arguable
> whether large applications could be practically written sticking strictly
> to ISO C (almost as surprising as Zack's claim that this was clearly
> impractical for Ada :-) I also found the idea that the only way to
> achieve portability is through use of conditional compilation to be
> surprising (I doubt this is true).

I've written a lot of portable C and C++; due to the lack of 
standards-compliant compilers or the use of platform-dependent 
facilities (e.g., GUIs), such code often contains conditional statements.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Ada policy

[Joseph S. Myers]

On Tue, 31 Aug 2004, Scott Robert Ladd wrote:

> I understood that you were discussing portability (based on your focus on
> int), which is often a matter of making certain that type "X" has a compatible
> range across multiple platforms. Thus the stdint.h definitions.
> 
> That is, of course, assuming you have a Standard C compiler across your target
> platforms. :)

Which is perhaps not wise in this regard if you want to rely on features 
GCC doesn't yet implement (<stdint.h>; see the last couple of comments in 
bug 448 for Geoff Keating's proposal to implement it) of a standard that 
has not yet been widely implemented.

Fortunately in this case you can substitute your own <stdint.h> if 
necessary using <limits.h> or autoconf if the target library doesn't have 
<stdint.h> or the more widely implemented <inttypes.h>.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Florian Weimer]

* Robert Dewar:

> Hmm .. http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
>
> seems to confirm my understanding, and actually that reference says it is
> an extension of the C99 definition. What you would want is the type
> int_least24_t, but that's not required to be defined. Am I
> misunderstanding here?

<stdint.h> is a huge improvement.  If your code is portable, it can't
make a difference if you use int_least24_t or int_least32_t.  In fact,
you could even substitute int32_t for int24_t, and the code would
still work as before.  (The need for precise bit counts only arises if
you have certain overflow semantics, which you get only for unsigned
types in standard C.)

By the way, your example

| So for example, there is no equivalent of
| 
|    type R is range -2**23 .. 2**23-1;
| 
| which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
| a 36 bit machine.

seems to lack an R'Base.  Otherwise, your comment about mapping is a
bit misleading.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> <stdint.h> is a huge improvement. 

Yes, absolutely!

> If your code is portable, it can't
> make a difference if you use int_least24_t or int_least32_t.  In fact,
> you could even substitute int32_t for int24_t, and the code would
> still work as before. 

Well .. you can make portable code by implementing a Turing machine and
doing everything at that level and "the code would still work as before",
but efficiency is not something you can afford to throw out of the window
when writing portable code.

Specifying int_least32_t on a 24 bit machine for quantities that could
fit fine in 24 bits is likely to be a severe efficiency hit. The whole
style in Ada is to specify types that accomodate the problem space and
then let the compiler choose efficient mappings.> By the way, your example

> | So for example, there is no equivalent of
> | 
> |    type R is range -2**23 .. 2**23-1;
> | 
> | which you expect to map into 24 bits on a 24 bit machine, and 36 bits on
> | a 36 bit machine.
> 
> seems to lack an R'Base.  Otherwise, your comment about mapping is a
> bit misleading.

The omission of an explicit base type is very definitely intentional here.
You are asking the compiler "you choose an efficient base type for me".
Specifying a base type is generally not what you want, since you do not
want to force the compiler to make an inefficient choice.

Re: Ada policy

[Robert Dewar]

Zack Weinberg wrote:

> [It's debatable whether it's practical to write a large complex piece
> of software in the C language as ISO-standardized, but at least it's
> possible to do so in the /de facto/ standard language.]

My final note on this issue, I am really surprised that it is debatable
for C whether it is practical to write large complex pieces of software
in standard C. I guess things are worse than I thought if that's the
case.

In Ada, it is most certainly practical to write completely portable
large complex applications in Ada, and we have several customers who
do this since their coding guidelines require such portability, and
indeed some of them are using more than one compiler in parallel.

But once again, although this is practical and possible, it is simply
not a design criterion for GNAT. Since we know we are being compiled
with GNAT we take advantage of its full features. If vendors of
proprietary compilers want to borrow some of our code, then they
can mess to make it work with their compilers.

Here's a specific example:

THere is a routine in Ada.Decimal that does high precision decimal
scaled division. Of course the body could be written in pure
Ada, but in GNAT you will find:

       procedure Divide
         (Dividend  : in Dividend_Type;
          Divisor   : in Divisor_Type;
          Quotient  : out Quotient_Type;
          Remainder : out Remainder_Type);

       pragma Import (Intrinsic, Divide);

The Ada standard defines the convention Intrinsic, but it is implementation
dependent what intrinsics are provided. The effect is similar to a built-in
in GCC, and the result is to let the compiler generate direct efficient
code for this operation.

Now if Aonix wants to borrow our implementations of decimal (they did borrow
some code at least at one point to fill in things they had not bothered to
implement themselves), then they will find this won't compile. Too bad as
far as we are concerned, being able to compile with Aonix is not one of
our coding requirements :-)

P.S. I know this is a run-time example, but it's a simple one to explain,
and there are many similar examples throughout the compiler.

Re: Ada policy

[Laurent GUERBY]

On Tue, 2004-08-31 at 20:10, Zack Weinberg wrote:
> People seem to be reacting way out of proportion to this particular
> observation.  There's good solid engineering reasons why you need GNAT
> to build GNAT and I don't mean to second-guess that.  

Thanks for the precision (was not clear to me).

> When I say I'm
> disappointed, that's an abstract observation on the state of the Ada
> language -- if it's not practical to write a large complex piece of
> software such as a compiler in the language as standardized, then the
> standard is less than useful, and that's disappointing.

That's not the point, it's practical to write large complex software
in Ada (I worked on "porting" n-million lines Ada application from
compilers and platforms without much trouble except long compile time on
old 16MB of RAM machines for software of such size :).

It's just that GNAT people choose to take advantage of non portable
feature they added as they saw fit since it had no practical drawback
(given the cross compilation abilities of GCC). 

This kind of liberty is only available for compiler writers that are
able to "bootstrap", and not for software in general, so no general
conclusion should be taken there :).

Laurent

Re: Ada policy

[Robert Dewar]

Laurent GUERBY wrote:

> This kind of liberty is only available for compiler writers that are
> able to "bootstrap", and not for software in general, so no general
> conclusion should be taken there :).

I wouldn't go that far. A lot of big applications using gcc (gnat,
or g++ or gnu-c or ..) decide that it is fine to restrict their application
to being compilable only with gcc.

For example, it is definitely attractive to use nested functions in C
if you decide to rely on gnu-c. This can for example make it
considerably easier to write thread-safe C (since what otherwise
might be global variables can be uplevel task-specific stack
references).

Re: Ada policy

[Robert Dewar]

Laurent GUERBY wrote:

> On Tue, 2004-08-31 at 16:39, Gabriel Dos Reis wrote:
> 
>>I think you could reason on facts: the C front-end!
> 
> 
> I'd say not relevant, the Ada subset used by GNAT is
> much more complex than C.

I think you missed the point. Gabriel was saying that even
the (much simpler) language of the C front end is unable
to meet the criterion of compiling with all possible previous
C compilers :-)

Re: Ada policy

[Florian Weimer]

* Zack Weinberg:

> I continue to be disappointed that an arbitrary standard-conforming
> Ada compiler cannot be used.

Have you actually seen any such compiler in the wild? 8-)

Of course it could be done, but how many GCC users would need such a
feature?  Maybe a dozen, but certainly not more.

Re: Ada policy

[Robert Dewar]

Florian Weimer wrote:

> Of course it could be done, but how many GCC users would need such a
> feature?  Maybe a dozen, but certainly not more.

I would be amazed if it were a dozen :-)

I would actually be surprised if there is even one user who wants to
bootstrap GNAT with other than a version of GNAT!

Re: Ada policy

[Joseph S. Myers]

On Mon, 30 Aug 2004, Zack Weinberg wrote:

> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

Ada changes do now come with associated documentation.  I don't think any 
of the other problems have been fixed; for example, fixes to bugs with 
public non-ACATS testcases don't get them added to the testsuite (and 
there is no harness to add them to) although a fair number of such 
testcases have been posted to the lists over the years which ought to be 
in the testsuite.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Ada policy

[Geoffrey Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> http://gcc.gnu.org/ml/gcc/2004-02/msg00859.html

I believe when I looked at this, I thought everything in it was reasonable.

I would actually add two extra requirements, which are the reasons why
*I* don't build or test Ada:

1. Since the Ada compiler cannot be bootstrapped from most system
   compilers, it must be at least as easy, if not easier, to
   cross-compile it from a system which does have GNAT installed.  At
   a minimum, it must be possible to easily build a cross Ada compiler
   for the other system, even when the other target is a host
   (including hosts for which binutils is not readily available, like
   AIX and Darwin), and then use that to build a native Ada compiler
   for the other system.

2. Since the Ada compiler and tools must be installed in binary form
   on the other system (because there is no compiler to build it from
   source), they must be fully relocatable, that is they must be able to
   be installed in any location; because the person doing the
   installation may not be able (or willing) to write it to /usr/local
   or wherever it was originally built for.  (I know the C compilers
   already do this, I am not sure if it really works for Ada).

Re: Ada policy

[Florian Weimer]

* Geoffrey Keating:

> 2. Since the Ada compiler and tools must be installed in binary form
>    on the other system (because there is no compiler to build it from
>    source), they must be fully relocatable, that is they must be able to
>    be installed in any location; because the person doing the
>    installation may not be able (or willing) to write it to /usr/local
>    or wherever it was originally built for.  (I know the C compilers
>    already do this, I am not sure if it really works for Ada).

The official GNAT 3.15p distributions are fully relocatable on
GNU/Linux and Solaris (I haven't checked Windows).  I haven't tried
this with FSF releases, though.

Re: Ada policy

[Robert Dewar]

Geoffrey Keating wrote:

> 1. Since the Ada compiler cannot be bootstrapped from most system
>    compilers, it must be at least as easy, if not easier, to
>    cross-compile it from a system which does have GNAT installed.  At
>    a minimum, it must be possible to easily build a cross Ada compiler
>    for the other system, even when the other target is a host
>    (including hosts for which binutils is not readily available, like
>    AIX and Darwin), and then use that to build a native Ada compiler
>    for the other system.

We build cross compilers all the time, in fact Richard does virtually
all his debugging on an opteron using cross-compilers for all other
targets.
> 
> 2. Since the Ada compiler and tools must be installed in binary form
>    on the other system (because there is no compiler to build it from
>    source), they must be fully relocatable, that is they must be able to
>    be installed in any location; because the person doing the
>    installation may not be able (or willing) to write it to /usr/local
>    or wherever it was originally built for.  (I know the C compilers
>    already do this, I am not sure if it really works for Ada).

GNAT can be installed anywhere, that's not a problem.

Re: Ada policy

[Florian Weimer]

* Laurent GUERBY:

> On Mon, 2004-08-30 at 21:28, Florian Weimer wrote:
>> I understand that Ada is already in much better shape than we expected
>> it to be before the tree-ssa merge (and that's certainly good news!),
>> but I really doubt we should make a release criterion the quality of a
>> component that has received very little testing by the general GCC
>> community.
>
> I'm just talking about bootstrap, passing ACATS and no known regression
> on two targets, not "quality" in general (whatever that means).

I was talking about bootstrap and ACATS, too, but on a more general
scale.  Today's x86 systems are far from being homogeneous.

> Is that what you want for Ada now?

You wrote that the GCC 3.4 release was pretty good from an Ada point
of view, and we didn't have any formalized Ada criteria for it.

As far as I can see, we haven't had a bootstrapping Ada compiler for
months.  (This is by no means a criticism, I note that we are still
way ahead of the original schedule, Ada-wise.  Certainly I didn't
expect Ada to be included in 3.5 at all, based on the discussion
before the tree-ssa merge.)  I think, however, that it is unreasonable
to expect that large fraction of GCC developers will be able to
_efficiently_ deal with Ada regressions before the 3.5 release, simply
because they lack an Ada toolchain that is in a well-defined state and
can be used to build a compiler and a working run-time environment.

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I think that GCC 3.5 is going to be a good release.  I also think that 
    the first release with major new technology (tree-ssa is easily the 
    biggest change to GCC in a decade) is going to have dot-zero properties: 
    it won't work perfectly for all people all of the time.

OK, I'm now totally confused.

If the "biggest change to GCC in a decade" doesn't justify changing the major
version number in your mind, then what would?

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Richard Kenner wrote:

>    I think that GCC 3.5 is going to be a good release.  I also think that 
>    the first release with major new technology (tree-ssa is easily the 
>    biggest change to GCC in a decade) is going to have dot-zero properties: 
>    it won't work perfectly for all people all of the time.
>
>OK, I'm now totally confused.
>
>If the "biggest change to GCC in a decade" doesn't justify changing the major
>version number in your mind, then what would?
>  
>
I have an answer to that question, but I don't think it's an important 
question right now, and I've said all along that I didn't feel 
passionately about it.

Right now, I'd like to focus on getting the release ready.  We can have 
the marketing debate later, if we must.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Mike Stump]

On Monday, August 30, 2004, at 07:26  AM, Mark Mitchell wrote:
> Right now, I'd like to focus on getting the release ready.  We can 
> have the marketing debate later, if we must.

I'd prefer that we just give our input to you, and let you pick an 
answer, and that this be done sooner, rather than at the last minute... 
  1/2 of the people won't be happy, but we have to just live with that.  
In fact, I'd say we already had the debate, and the version number 
hasn't changed, therefore, the people that wanted 4.0 lost.  
Personally, 2 new frontends and a new optimization infrastructure seems 
to me to live up to requirement...

So, feel free to just announce the decision...  whatever it is...  
Deciding to not decide, is a decision.

Re: GCC 3.5 Status (2004-08-29)

[Nathanael Nerode]

>For everything not explicitly mentioned below, Stage 3 will begin
>September 5th as announced.

I notice that the, uh, "project" to get Ada bootstrapping (Kenner, when can
we expect this?) is not listed.  These changes will presumably be accepted
in stage 3?

However, I'm beginning to worry that Ada is going to delay the release
of GCC 3.5 substantially if it's not bootstrapping soon, because the long
period without Ada bootstrapping is likely to lead to bug discoveries when
Ada is revived from the dead.

Is Ada functioning a requirement for the release?  If so it seems a moderately
bad idea to go into stage 3 with it totally busted.

-- 
This space intentionally left blank.

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    PS I should also note Ada still does not build at least at the last know
    report, we got from Kenner and other Ada Core people.

Right.  I was away for a week and couldn't work on it.  The problem was
first the integer cache and then some random change that made a kludge
that was used for TYPE_LANG_SPECIFIC no longer work.  The first was
fixed in that code and I removed the kludge today.

Right now with my tree I have a bootstrap, but one of the ACATS tests that
at one point worked regressed.

I'm going to try to get things more checked in before dealing with that
regression since what I have is far better tnan what's checked in now.  I
think there are still a handful of things where it isn't clear exactly how to
fix things, but I need to go through stuff more methodically to see exactly
what they are.  That should happen in the next 2-3 days.

Because any remaining bugs can be fixed in Stage 3, I don't see Ada
as a constraint on the 3.5 schedule.

Speaking of Ada, I assume we'll follow the same procedures we did in 3.4
and let Arno be the judge of what changes can go into the Ada files when,
correct?

GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

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


-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com


[-- Attachment #2: gcc-status.txt --]
[-- Type: text/plain, Size: 7404 bytes --]

Asking for project submissions was certainly useful.  I got 45 such
submissions.  Henceforth, I plan to request these submissions much
earlier in the release process.

Below is a list of all of the projects received.  There are dates with
some of the projects.  Those are deliver-by dates.  If your project is
not submitted by that point, with appropriate testing, etc., we're
going to pass on it.  Some of the dates are earlier than the
submitter's estimated delivery-by dates.  I know these dates may not
be achievable.  There's no obligation on the submitter to try to meet
these dates -- but if you don't, we'll move on without you.  If the
project is submitted, but not reviewed, by that date, we'll try to get
it incorporated.  Of course, just because your project is submitted by
the deliver-by date doesn't ensure acceptance; you must still
convinvce the appropriate maintainers that your change is worthwhile.

For everything not explicitly mentioned below, Stage 3 will begin
September 5th as announced.  We'll fully enter Stage 3 on September
26th, which is one week after the latest deliver-by date below, to
give us some time to review things submitted by the September 19th
dates.  The reason that other "safe" Stage 2-ish changes will not be
accepted between September 5th and October 1st is that (a) history has
shown that such changes are often not as safe as submitters think, and
(b) there are lots of bugs to fix.  Furthermore, I believe it to be
the case that, in the timeframe in question, bigger performance wins
can be had by tuning and improving the existing code than by adding
new optimizations.

We will include projects marked for postponement until GCC 3.6 below
if they have already been submitted or make it in before September
5th, so as to be consistent with earlier announcements.

If you disagree with my decisions, feel free to send me a message
explaining why you think that the decision was inappropriate.  I will
consider your position, but you will have to be convincing in order to
change my mind.  To be convincing, make sure you quantify the win: it
you want me to believe that your optimization is worthwhile tell me
how much it improves a well-known benchmark.

-------------
Cleanups, etc.
-------------

There were a few submissions that are cleanups, or infrastructure
improvements, on which nothing else depends, and which -- according to
the submitters themselves -- do not bring substantial user-visible
improvements.  Those will not be accepted past the previously
announced Stage 3 cutoff date: September 5th.  These include:

* Immediate use integration [MacLeod] 

* Top-level bootstrap [Bonzini/Nerode]

* Automatic dependency for GCC builds [Weinberg]

* Convert RTL passes to use pass manager [Nerode/Bonzini]

These changes are all good -- but get them in before September 5th, or
hold on to them until GCC 3.6.

--------------------------------
Target/language-specific changes
--------------------------------

As a general rule, I'm going to delegate target-specific and
language-specific changes to the discretion of the appropriate
maintainers, at least until we make the release branch, and perhaps
longer.  So, for example, the Java ABI rework can go in during Stage
3, if the Java maintainers think that's OK, and the MIPS paired-float
work can go in if the MIPS maintainers think it's OK.  Maintainers,
please exercise good judgement here, and err on the side of caution.
If your port/language gets all messed up, I'll be very hesitant to
delegate to you in future.  I'm not delgating similar responsibilities
for common code (including optimizations) because the consequences of
changes there are much more far-reaching.

This delgation rule applies to the following language-specific
changes:

* Member class template as template friend (PR13495) [Lerdsuwanakij]

* GCJ BC ABI [Haley/McKinlay/Tromey]

* C90 [Myers]

* Objective-C++ [Laski]

* Add "Class <protocol>" support to the ObjC frontend [Ayers]

In addition, the SC has promised Zem that we wil get Objective-C++
into GCC 3.5.  Therefore, we will not release without Objective-C++,
unless something seems to have gone horribly awry.

This delgation rule also applies to the following target-specific
changes:

* PowerPC GNU/Linux dot-smybol removal [Modra]

* MIPS paired single support [Wilson]

* PA long conditional branches [Anglin]

* PA GNU/Linux TLS [Anglin]

* PA HP-UX Ada [Anglin]

* 64-bit PA HP-UX shared libgcc support [Anglin]

* Windows TLS/weak/shared/versioning support [LaFramboise]

This delegation rule does *not* apply to the following changes, as I
consider them to have too high a risk/reward ratio, and they will
therefore be postponed until GCC 3.6:

* 64-bit PA HP-UX DWARF2 Exceptions [Anglin]

* PA HP frame layout [Anglin]

* IA64 floating-point model [Weinberg]

* HP-UX __fpreg support [Weinberg]

* HP-UX #pragma _USE_SF support [Weinberg]

* IA64 division/sqrt scheduling improvements [Weinberg]

If these get done, and look very solid, and everyone wants them, I'll
reconsider.

-------------------------
Compile-Time Improvements
-------------------------

There were three submissions relating primarily to compile-time
improvements.  Since this has been a persistent problem, we'll allow
these changes for GCC 3.5 -- if they can get finished quickly enough.

* Fix/finish --enable-mapped-location [Bothner]

  September 19

* Edges-in-vectors conversion [Elliston]

  September 19

* General compile-time performance improvements [Weinberg]

  This project is a catch-all.  We will decide these on a per-change
  basis.  Compile-time performance is a major issue.  As in previous
  Stage 3s, and even on release branches, these changes will be OK,
  with appropriate maintainer approval -- but more localized, smaller
  changes will of course be favored over bigger changes.

--------------------
Optimization Changes
--------------------

There are a ton of these: a lot of people are working hard on a lot of
really interesting projects.  What I've done with these is selected
those that I think have the best risk/reward/timeliness tradeoffs.

* Analysis of usage of compilation unit static variables and removal
  of spurious clobbering vdef based on the information [Zadeck]

  September 12

* Use the previous project to promote non-escaping static variables
  into true ssa variables [Zadeck]

  September 19

* Vectorize unknown-loop-bound support [Golovanevsky]

  September 12

* Vectorizer peeling-for-alignment support [Golovanevsky]

  September 19

* Vectorizer additional data-references support [Rosen]

  September 19

* Linear loop transforms [Berlin]

  September 12

* Variable expansion optimization [Eres]

  September 12

* LNO branch merge [Dvorak]

  September 19

* Tree-based branch prediction [Hubicka]

  September 5 

* Tree-based profile-directed feedback [Hubicka]

  September 12

The following changes will be postponed until GCC 3.6.  These changes
either provide too little benefit, are too risky, or will take too
much time to complete.

* Tree-based coverage [Hubicka]

* Aliasing improvements for structure fields [Berlin]

* Value range propagation [Novillo]

* CFG-based inliner [Hastings]

* Vectorizer misaligned-loads support [Naishlos]

* Vectorizer pattern recognition support [Naishlos]

* If-conversion and vectorization of conditional code [Patel]

* SMS improvements [Hagog, Markovitch]

Re: GCC 3.5 Status (2004-08-29)

[Andrew Pinski]

On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:

> * Aliasing improvements for structure fields [Berlin]

Actually without this, we will produce wrong code so I think this one
should be rethought about and not delaying it until 3.6.

See PR 15262.

> * If-conversion and vectorization of conditional code [Patel]

Part of this one has been submitted already so it should be able to get 
into
3.5.0 without the trouble and it is already on the apple-ppc-branch and 
the
lno branch.
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02291.html>

> * Analysis of usage of compilation unit static variables and removal
>   of spurious clobbering vdef based on the information [Zadeck]


This has been submitted already with almost no context review and no
approval ....
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02187.html>

Thanks,
Andrew Pinski


PS I should also note Ada still does not build at least at the last know
report, we got from Kenner and other Ada Core people.

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Andrew Pinski wrote:

>
> On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:
>
>> * Aliasing improvements for structure fields [Berlin]
>
>
> Actually without this, we will produce wrong code so I think this one
> should be rethought about and not delaying it until 3.6.

I think you are talking about something different.

In particular, this is work that Dan said he could not complete for 
several months.  I fail to  believe that PR 15262 cannot be fixed 
without adding lots of new optimization infrastructure.

>> * If-conversion and vectorization of conditional code [Patel]
>
>
> Part of this one has been submitted already so it should be able to 
> get into
> 3.5.0 without the trouble and it is already on the apple-ppc-branch 
> and the
> lno branch.
> <http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02291.html>

If-conversion has been submitted.  There are non-trivial issues with the 
patch according to Richard.  If this gets done before Septemberr 5th, I 
don't object.  Otherwise, we don't need this before GCC 3.5.

>> * Analysis of usage of compilation unit static variables and removal
>>   of spurious clobbering vdef based on the information [Zadeck]
>
> This has been submitted already with almost no context review and no
> approval ....
> <http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02187.html>

Yes, I hope this will get finished.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Sun, 29 Aug 2004, Mark Mitchell wrote:

> Andrew Pinski wrote:
>
>> 
>> On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:
>> 
>>> * Aliasing improvements for structure fields [Berlin]
>> 
>> 
>> Actually without this, we will produce wrong code so I think this one
>> should be rethought about and not delaying it until 3.6.
>
> I think you are talking about something different.
>
> In particular, this is work that Dan said he could not complete for several 
> months.  I fail to  believe that PR 15262 cannot be fixed without adding lots 
> of new optimization infrastructure.

This is correct (the time estimate).
Being realistic, without help, it will be several months before it can be 
complete (IE when it's not causing regressions and all latent bugs are 
fixed).Of course, if it  doesn't expose any latent bugs, causes no 
testsuite failures, a good design for how to integrate the information 
is quickly agreed upon, and others were to help out with the integrating 
(there are a few pieces that should be able to be parallelized once a 
design is agreed upon), the time could be significantly shortened.

A lot of that  time is going to be spent in the  infrastructure necessary 
to make this useful, which encompasses a lot of 
the low hanging fruit by definition (simply saying that a store to a.b 
doesn't kill the entire value of a).
In fact, this is actually where most of these months is going to be spent 
(and fixing latent bugs/problems that pop up as a result).

Actually writing something that produces the alias information we want 
(knowing whether p->a and p->b alias, knowing whether x[0] and x[1] 
alias), and  making sure it gives correct 
results for corner cases, is what i saw as the easy part, at least for me.
This is, in fact, done, bootstrapping, and passes all it's internal 
checking during bootstrap.  I've tested it on some wonky cases, and it 
produces what appear to be correct results.
I can post it tommorrow if people want to see it.
There are improvements that could be made to the results, of 
course, and TODO's, but none that were so important as the basic 
information.

Using the information, of course, is the part that is going to require the 
architectural changes, design work, etc.

I just sent some email to Diego and RTH this morning to see if they had 
any thoughts about what to do here, along with a somewhat simplistic idea 
of how to solve the "a.b vs a.c" issue.

I'll note that a design is agreed upon for the "make stores 
to a.b not kill a.c" issue, if others were to help implement it, we could 
probably tackle it before 3.5 (IE in the next month), and i would happily 
do the rest of the work alone (if need be) for "p->a vs p->b, a[0] vs 
a[1]", etc

--Dan

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 01:17, Mark Mitchell wrote:
> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
> 
> * Aliasing improvements for structure fields [Berlin]

I believe this is a big mistake.  Yes I know this may or may not be
ready on time according to _your_ schedule as the RM.  But you should
realize that this analysis is absolutely critical if GCC 3.5 is going
to perform reasonably well.

I have done extensive testing of the effect of some RTL passes on GCC
bootstraps over the past few weeks. One of my findings is that:

1) almost all opportunities for jump threading we still do on RTL, and
2) almost all (like ~99%) store motion opportunities,

only happen because we miss alias information for fields at the tree
level.  We *need* this alias analysis to be able to simplify or remove
some RTL passes.  In the end, that is the *only* way to retrieve the
compiler speed we have lost with ~60 new passes we do since tree-ssa
was merged.

[ That doesn't even take into account the extra optimizations we can
  do on trees with this information.  ]

This new optimization frame work we have is fun and cool and gread and
all.  But I don't believe GCC 3.5 should be released without alias
analysis that is at least capable of catching as much as what we catch
now on RTL.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 01:17, Mark Mitchell wrote:
>  
>
>>The following changes will be postponed until GCC 3.6.  These changes
>>either provide too little benefit, are too risky, or will take too
>>much time to complete.
>>
>>* Aliasing improvements for structure fields [Berlin]
>>
>>    
>>
>But you should
>realize that this analysis is absolutely critical if GCC 3.5 is going
>to perform reasonably well.
>  
>
I am not convinced of this statement. 

First, the compiler speed argument mostly affects optimizing 
compilations, where compile-times are much less critical than 
non-optimizing compilations.  I'm sure that people will want to argue 
this point, but I've been talking with customers for a decade and the 
ones concerned about compile-times are almost always willing to have 
optimizing compilation take longer.

Second, Dan said it will take 2-3 months to complete this work.  That's 
a lot of time, and indicates a big project.  I am confident that there 
are alternatives that, while perhaps less comprehensive, get enough of 
the common cases to achieve most of the benefits.

Third, if this change is so vital, then we should be willing to drop 
some other changes in favor of this one, so that people can work with 
Dan to finish this one.  Why don't you suggest some changes that are 
already on the list that you'd be willing to give up?

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 02:03, Mark Mitchell wrote:
> Steven Bosscher wrote:
> >On Monday 30 August 2004 01:17, Mark Mitchell wrote:
> >>The following changes will be postponed until GCC 3.6.  These changes
> >>either provide too little benefit, are too risky, or will take too
> >>much time to complete.
> >>
> >>* Aliasing improvements for structure fields [Berlin]
> >
> >But you should
> >realize that this analysis is absolutely critical if GCC 3.5 is going
> >to perform reasonably well.
>
> I am not convinced of this statement.
>
> First, the compiler speed argument mostly affects optimizing
> compilations, where compile-times are much less critical than
> non-optimizing compilations.  I'm sure that people will want to argue
> this point, but I've been talking with customers for a decade and the
> ones concerned about compile-times are almost always willing to have
> optimizing compilation take longer.

Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
just about every project using GCC complaining about how GCC gets slower
with each release?

Are you aware of the compile time comparisons from Diego?
http://people.redhat.com/dnovillo/spec2000/gcc/individual-build-secs_elapsed.html

As you can see, we are between 25 and 100% slower on almost _every_ SPEC
benchmark that compiled with older GCCs as well.  Only eon (C++) builds
faster, and ammp is about the same as GCC 3.4.
For most benchmarks we need 2.5 - 3 times as long as icc - which happens
to also outperform GCC on just about every benchmark.

People may be willing to accept a slower compiler when optimizing, but 
by now even I am wondering if I should just switch to a faster compiler
that also produces better code on this very popular target  ;-)


> Second, Dan said it will take 2-3 months to complete this work.  That's
> a lot of time, and indicates a big project.

Dan has so far been entirely on his own.  Note that his alias solver is
as good as ready, it just needs to be integrated in CC.  I don't know how
much work it would take, but apparently a lot.  Perhaps if more people
could help out (which is actually already happening), this doesn't have
to take 3 months.  Dan/Diego/RTH can probably come up with more comments
on this.


>  I am confident that there
> are alternatives that, while perhaps less comprehensive, get enough of
> the common cases to achieve most of the benefits.

What is your confidence based on?  What common cases?  Did Dan tell you
about the issues that he's fighting?  No "less comprehensive" solution
exists that will not run into the exact same problems.


> Third, if this change is so vital, then we should be willing to drop
> some other changes in favor of this one, so that people can work with
> Dan to finish this one.  Why don't you suggest some changes that are
> already on the list that you'd be willing to give up?

The things I currently work on that I would drop right away:
* Edges-in-vectors conversion [Elliston]
* Tree-based profile-directed feedback [Hubicka]

Things that I think are not as important as beter AA:
* Linear loop transforms [Berlin]
* Variable expansion optimization [Eres]
* Tree-based branch prediction [Hubicka]
...and probably other stuff, but these are the only ones from which I
think we reasonably expect that they would help Dan (hey, is he on that
list?!) with his AA work.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 02:03, Mark Mitchell wrote:
>  
>
>>Steven Bosscher wrote:
>>    
>>
>>>On Monday 30 August 2004 01:17, Mark Mitchell wrote:
>>>      
>>>
>>>>The following changes will be postponed until GCC 3.6.  These changes
>>>>either provide too little benefit, are too risky, or will take too
>>>>much time to complete.
>>>>
>>>>* Aliasing improvements for structure fields [Berlin]
>>>>        
>>>>
>>>But you should
>>>realize that this analysis is absolutely critical if GCC 3.5 is going
>>>to perform reasonably well.
>>>      
>>>
>>I am not convinced of this statement.
>>
>>First, the compiler speed argument mostly affects optimizing
>>compilations, where compile-times are much less critical than
>>non-optimizing compilations.  I'm sure that people will want to argue
>>this point, but I've been talking with customers for a decade and the
>>ones concerned about compile-times are almost always willing to have
>>optimizing compilation take longer.
>>    
>>
>
>Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
>just about every project using GCC complaining about how GCC gets slower
>with each release?
>  
>
Obviously, this is not ideal.  However, we have few practical 
alternatives.  I am not convinced that any further delay will get us 
better results.  I do not see a broad committment to improving 
compile-time speed when optimizing: in fact, I got zero proposals from 
people planning to work specifically on that issue. 

We have no way of knowing for sure that Dan's work will help here 
either, or how many follow-on effects there will be.  If Dan's work does 
what we expect, then we can turn off some RTL optimizers.  That will 
help, but I doubt it will help by a factor of two.  We've been looking 
at compile-time issues a lot lately, and generally these turn out to be 
pretty subtle.  Since Dan's work requires touching lots of code, it will 
introduce bugs.  They will have to be fixed.  We will likely uncover 
other latent bugs as a result of Dan's code making things more aggressive.

Maintaining compilation speed was a precondition set by the SC for the 
tree-ssa merge.  If that condition was not met, then perhaps the merge 
should not have been performed.  The fact that it was probably indicates 
that people weren't too worried about these compile-time effects.

I continue to think it will take at least another several months to 
really get to the point where tree-ssa is unambiguously better 
(consistently better code, consistently better compile-times, fewer 
bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June, 
and SC approves, it's OK with me.  Otherwise, I think we proceed, and 
accept that the release will be useful to some people and less useful to 
others.  (It will, for example, be useful to people who need support for 
new targets, or want gfortran, or want faster non-optimizing compile 
times, which we are now seeing for some C++ programs.)  There are always 
people who declare any given release to be "totally broken".

>>the common cases to achieve most of the benefits.
>>    
>>
>
>What is your confidence based on?  What common cases?  Did Dan tell you
>about the issues that he's fighting?  No "less comprehensive" solution
>exists that will not run into the exact same problems.
>  
>
My confidence is based on the fact that there are generally such 
solutions to most such problems in software engineering.  Perhaps this 
is the very rare case where there is no acceptable short-term solution 
that gets much of the win, but I'd be surprised.

>>Third, if this change is so vital, then we should be willing to drop
>>some other changes in favor of this one, so that people can work with
>>Dan to finish this one.  Why don't you suggest some changes that are
>>already on the list that you'd be willing to give up?
>>    
>>
>
>The things I currently work on that I would drop right away:
>* Edges-in-vectors conversion [Elliston]
>* Tree-based profile-directed feedback [Hubicka]
>
>Things that I think are not as important as beter AA:
>* Linear loop transforms [Berlin]
>* Variable expansion optimization [Eres]
>* Tree-based branch prediction [Hubicka]
>...and probably other stuff, but these are the only ones from which I
>think we reasonably expect that they would help Dan (hey, is he on that
>list?!) with his AA work.
>
That's roughly the same list I would have come up with, with the 
exception of Elliston's changes, which I think are important precisely 
because they will likely reduce memory usage and help compile times.  If 
Dan, Jan, and Revital are willing to abandon their other projects and 
will commit to working with you on aliasing, and together, you think 
that you can get things done much more quickly, let me know.  (There is 
probably not much to be done for linear loop transforms, since Dan 
indicates that it is already submitted.)  I am willing to trade.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Andrew Pinski]

On Aug 29, 2004, at 5:53 PM, Mark Mitchell wrote:

> Maintaining compilation speed was a precondition set by the SC for the 
> tree-ssa merge.  If that condition was not met, then perhaps the merge 
> should not have been performed.  The fact that it was probably 
> indicates that people weren't too worried about these compile-time 
> effects.


There has been a couple of cases where compile time has actually speed 
up
a huge amount even with the new optimization so it was no a clear cut if
we should not merge or not.

I should note that the bootstrap time feels longer but I could be 
imagining
things.


-- Pinski

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Andrew Pinski wrote:

>
> On Aug 29, 2004, at 5:53 PM, Mark Mitchell wrote:
>
>> Maintaining compilation speed was a precondition set by the SC for 
>> the tree-ssa merge.  If that condition was not met, then perhaps the 
>> merge should not have been performed.  The fact that it was probably 
>> indicates that people weren't too worried about these compile-time 
>> effects.
>
>
>
> There has been a couple of cases where compile time has actually speed up
> a huge amount even with the new optimization so it was no a clear cut if
> we should not merge or not.

I am not criticizing the decision to merge.  In fact, I am not at all 
surprised that it is faster sometimes and slower other times: the same 
is true of the generated code.  (There are also some new bugs, and some 
old bugs fixed, and...)  The tree-ssa changes are a huge perturbation 
and, as such, it's hard to make absolute "it's better" or "it's worse" 
statements.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Joseph S. Myers]

On Sun, 29 Aug 2004, Andrew Pinski wrote:

> I should note that the bootstrap time feels longer but I could be imagining
> things.

Bootstrap plus testsuite run time has been slowing down, by actual 
observation (3.5 hours three months ago, 4 hours now; 45 minutes 3.5 years 
ago), but because of the additional code being added to the compilers, 
runtime libraries and testsuites that isn't really something to use as a 
release criterion; users only build a release once (or once per system).  
(I'd be very unlikely to object to a testsuite addition on the grounds of 
increased testing time.)  The time to build a fixed body of code with 
different compilers, as shown for example in the SPEC timings, is the more 
useful comparison since it avoids mixing the two variables of what is 
being compiled and what is doing the compiling.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: GCC 3.5 Status (2004-08-29)

[Giovanni Bajo]

Mark Mitchell wrote:

> If people want to put GCC 3.5 off until next
> June, and SC approves, it's OK with me.

I think this should be seriously considered. Given the large number of
incomplete projects (partly merged like the vectorizer, or being worked on
offline), and the fact that we are currently maintaing *two* stable release
branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
months could be a good compromise. What do others think about this?

> Otherwise, I think we
> proceed, and accept that the release will be useful to some people
> and less useful to others.  (It will, for example, be useful to
> people who need support for new targets, or want gfortran, or want
> faster non-optimizing compile times, which we are now seeing for some
> C++ programs.)

As for C++ programs, I would like to remember that when tree-ssa was merged,
there were big C++ compile time issues at -O0, which used to be in the merge
requirement list, but were not met. There was agreement that these would be
tackled after the merge, possibly by running a couple of cleanup optimization
passes (DCE/CCP). I never heard of this project again since then, and the
issues seems to have been forgotten. I am sure I am not the only one who cares
about C++ compilation times at -O0: we got substantially better with 3.4 (even
wrt 2.95), but now we are regressing way too much.

IMHO, bugs like PR 15678 (C) and PR 13776 (C++) should be showstoppers for
branching 3.5.

Giovanni Bajo

Re: GCC 3.5 Status (2004-08-29)

[Matt Austern]

On Aug 29, 2004, at 7:00 PM, Giovanni Bajo wrote:

> Mark Mitchell wrote:
>
>> If people want to put GCC 3.5 off until next
>> June, and SC approves, it's OK with me.
>
> I think this should be seriously considered. Given the large number of
> incomplete projects (partly merged like the vectorizer, or being 
> worked on
> offline), and the fact that we are currently maintaing *two* stable 
> release
> branches, I don't think we should *rush* at releasing 3.5. Waiting 
> another 6
> months could be a good compromise. What do others think about this?
>
>> Otherwise, I think we
>> proceed, and accept that the release will be useful to some people
>> and less useful to others.  (It will, for example, be useful to
>> people who need support for new targets, or want gfortran, or want
>> faster non-optimizing compile times, which we are now seeing for some
>> C++ programs.)
>
> As for C++ programs, I would like to remember that when tree-ssa was 
> merged,
> there were big C++ compile time issues at -O0, which used to be in the 
> merge
> requirement list, but were not met. There was agreement that these 
> would be
> tackled after the merge, possibly by running a couple of cleanup 
> optimization
> passes (DCE/CCP). I never heard of this project again since then, and 
> the
> issues seems to have been forgotten. I am sure I am not the only one 
> who cares
> about C++ compilation times at -O0: we got substantially better with 
> 3.4 (even
> wrt 2.95), but now we are regressing way too much.

You are not the only person who cares about C++ compilation times at 
-O0.  This is a major concern for Apple, and I expect that improving 
C++ -O0 compilation time will be my primary activity for some time.  I 
don't think the current status it too awful, actually, but we do still 
have a way to go.

Do you have any suggestions for improving -O0 compile speed?

			--Matt

Re: GCC 3.5 Status (2004-08-29)

[Joe Buck]

On Sun, Aug 29, 2004 at 07:46:31PM -0700, Matt Austern wrote:
> You are not the only person who cares about C++ compilation times at 
> -O0.  This is a major concern for Apple, and I expect that improving 
> C++ -O0 compilation time will be my primary activity for some time.  I 
> don't think the current status it too awful, actually, but we do still 
> have a way to go.
> 
> Do you have any suggestions for improving -O0 compile speed?

It would seem to me that doing some relatively simple optimizations at
-O0, focused on reducing code size while preserving observable values (so
people using debuggers don't notice), should speed up -O0 by reducing the
amount of RTL that has to be turned into instructions, and reducing the
size of the files that must be processed by the assembler and linker.

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Mark Mitchell wrote:
| 
| > If people want to put GCC 3.5 off until next
| > June, and SC approves, it's OK with me.
| 
| I think this should be seriously considered. Given the large number of
| incomplete projects (partly merged like the vectorizer, or being worked on
| offline), and the fact that we are currently maintaing *two* stable release
| branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
| months could be a good compromise. What do others think about this?

I agree with your general sentiment.  We rushed to release 3.4.0
because it was thought 3.5.0 would bring the bonus of changes
happening in 3.4.0.  As a matter of fact, we now get another set of
new things whose bonuses are promised for the future.
What are our release criteria?  Sorry to ask the trivial, but it is
because I'm unclear about what we're after.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>"Giovanni Bajo" <giovannibajo@libero.it> writes:
>
>| Mark Mitchell wrote:
>| 
>| > If people want to put GCC 3.5 off until next
>| > June, and SC approves, it's OK with me.
>| 
>| I think this should be seriously considered. Given the large number of
>| incomplete projects (partly merged like the vectorizer, or being worked on
>| offline), and the fact that we are currently maintaing *two* stable release
>| branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
>| months could be a good compromise. What do others think about this?
>
>I agree with your general sentiment.  We rushed to release 3.4.0
>because it was thought 3.5.0 would bring the bonus of changes
>happening in 3.4.0.  
>
I disagree with that analysis.  GCC 3.4.0 was a pretty good release, as 
evidence by the fact that the major distros have moved to it or are 
moving towards it.  Certainly, it's the best C++ release we've ever had, 
and the generated code is better than previous releases.  In hindsight, 
the c-decl stuff was something of a mess, but it's hard to be perfect.

>What are our release criteria?  Sorry to ask the trivial, but it is
>because I'm unclear about what we're after.
>  
>
There is no single answer.  The GNU/Linux distro vendors want things, 
embedded people want things, hardware vendors what things, and other 
people want  things.  And, everyone wants the release schedule to line 
up with their own personal and/or organizational schedules.

As the RM, I want releases that are both timely and of high-quality.  
These two things cannot be entirely traded against each other: longer 
release cycles do not necessarily lead to higher quality.  In fact, they 
can lead to lower quality, as more and more changes go in, sometimes 
without corresponding problem-solving efforts.  I also don't think that 
"wait until it is ready" is a practical method for a project this big 
with this much change and with so much inter-dependency between components.

I think that GCC 3.5 is going to be a good release.  I also think that 
the first release with major new technology (tree-ssa is easily the 
biggest change to GCC in a decade) is going to have dot-zero properties: 
it won't work perfectly for all people all of the time.  Since everyone 
else (including Oracle, Microsoft, Red Hat, etc.) has that problem with 
huge revisions, I think we will have problems too -- independently of 
exactly when we do a release.  Oh, well.

I would like to get the other improvements in GCC 3.5.0 (new target 
support, etc.) released and I also think it would be very good for us to 
focus for a while on fixing bugs rather than adding features.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| >What are our release criteria?  Sorry to ask the trivial, but it is
| >because I'm unclear about what we're after.
| >
| There is no single answer.  The GNU/Linux distro vendors want things,
| embedded people want things, hardware vendors what things, and other
| people want  things.  And, everyone wants the release schedule to line
| up with their own personal and/or organizational schedules.
| 
| As the RM, I want releases that are both timely and of high-quality.
| These two things cannot be entirely traded against each other: longer
| release cycles do not necessarily lead to higher quality.  In fact,

If you're saying that having a release cycle of ten years is not
automatically going make the release of good quality, I can only agree
with you.

Making regular bug-fix releases at regularly spaced times makes good
sense to me.  What I'm unclear about is what we want for the *major*
releases.  Do we just want them every 6 months?  Do we drive it by
quality?  If by quality, what are the quality criteria?  I suspect
that question is harder than the previous to answer because we don't
seem to have metrics that throw numbers at us.  I don't think we have
answers for time and quality combined; or at least I'm just unable to
find where we're consistently applying them.

| they can lead to lower quality, as more and more changes go in,
| sometimes without corresponding problem-solving efforts.  I also don't
| think that "wait until it is ready" is a practical method for a
| project this big with this much change and with so much
| inter-dependency between components.

Again, I agree.  However, because the project is that big, I believe
branching  proposals should meet consensus among developers.

| I think that GCC 3.5 is going to be a good release.  I also think that
| the first release with major new technology (tree-ssa is easily the
| biggest change to GCC in a decade) is going to have dot-zero
| properties: it won't work perfectly for all people all of the time.
| Since everyone else (including Oracle, Microsoft, Red Hat, etc.) has
| that problem with huge revisions, I think we will have problems too --
| independently of exactly when we do a release.  Oh, well.

The issue is not whether we're going to have dot zero problems or
not.  But what is knowingly and with consensus decided to be included
in that set.

I'm not trying to make your job harder -- the RM position is alrady
hard enough.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Making regular bug-fix releases at regularly spaced times makes good
>sense to me.  What I'm unclear about is what we want for the *major*
>releases.  Do we just want them every 6 months?  Do we drive it by
>quality?  If by quality, what are the quality criteria?  I suspect
>  
>
We cannot drive it purely by quality, since we will never get quality 
unless we decide that we're going to make a release.  The level of 
bug-fixing activity goes up steeply as we approach a release: people 
start to fear that "their" platform/language/etc. will not work well.  
That's why we use a combination: drive by time, and then push for 
quality towards that date.

>| they can lead to lower quality, as more and more changes go in,
>| sometimes without corresponding problem-solving efforts.  I also don't
>| think that "wait until it is ready" is a practical method for a
>| project this big with this much change and with so much
>| inter-dependency between components.
>
>Again, I agree.  However, because the project is that big, I believe
>branching  proposals should meet consensus among developers.
>  
>
In contrast, I don't see consensus as achievable in this group.  We 
barely get consensus on technical issues, let alone on priorities.

Instead, I see my job as to take input, ponder it, consult with people, 
and make decisions.  The decisions I made about 3.5 were made with lots 
of input from lots of people -- developers, users, and other 
stakeholders -- and informed by discussions with people going back as 
far as the summit in Ottawa.  I don't expect everyone to be 100% happy 
about my decisions; I only hope to do a good enough job of being fair 
and reasonable that people respect them.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Making regular bug-fix releases at regularly spaced times makes good
| >sense to me.  What I'm unclear about is what we want for the *major*
| >releases.  Do we just want them every 6 months?  Do we drive it by
| >quality?  If by quality, what are the quality criteria?  I suspect
| >
| We cannot drive it purely by quality, since we will never get quality
| unless we decide that we're going to make a release.  The level of
| bug-fixing activity goes up steeply as we approach a release: people
| start to fear that "their" platform/language/etc. will not work well.
| That's why we use a combination: drive by time, and then push for
| quality towards that date.
| 
| >| they can lead to lower quality, as more and more changes go in,
| >| sometimes without corresponding problem-solving efforts.  I also don't
| >| think that "wait until it is ready" is a practical method for a
| >| project this big with this much change and with so much
| >| inter-dependency between components.
| >
| >Again, I agree.  However, because the project is that big, I believe
| >branching  proposals should meet consensus among developers.
| >
| In contrast, I don't see consensus as achievable in this group.  We

That says a lot.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Making regular bug-fix releases at regularly spaced times makes good
>| >sense to me.  What I'm unclear about is what we want for the *major*
>| >releases.  Do we just want them every 6 months?  Do we drive it by
>| >quality?  If by quality, what are the quality criteria?  I suspect
>| >
>| We cannot drive it purely by quality, since we will never get quality
>| unless we decide that we're going to make a release.  The level of
>| bug-fixing activity goes up steeply as we approach a release: people
>| start to fear that "their" platform/language/etc. will not work well.
>| That's why we use a combination: drive by time, and then push for
>| quality towards that date.
>| 
>| >| they can lead to lower quality, as more and more changes go in,
>| >| sometimes without corresponding problem-solving efforts.  I also don't
>| >| think that "wait until it is ready" is a practical method for a
>| >| project this big with this much change and with so much
>| >| inter-dependency between components.
>| >
>| >Again, I agree.  However, because the project is that big, I believe
>| >branching  proposals should meet consensus among developers.
>| >
>| In contrast, I don't see consensus as achievable in this group.  We
>
>That says a lot.
>  
>
Note that I didn't say "cooperation"; I said "consensus", which means 
that everyone agrees.

This is a group that cooperates well, but I don't think it's very easy 
to reach consenus among groups with O(100) people.  We often don't even 
get consensus on technical issues; we often instead defer to a 
maintainer to make a decision, or put off making one altogether.  When 
we do try for consensus, it's often among groups (the C++ maintainers, 
people who know a lot about reload, etc.) that are at least two orders 
of magnitude smaller than the group as a whole.  Even the SC doesn't 
always get consensus; we vote, and often have split votes.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Mark Mitchell <mark@codesourcery.com> writes:
| >
| >| Gabriel Dos Reis wrote:
| > | | >Making regular bug-fix releases at regularly spaced times makes
| > good
| >| >sense to me.  What I'm unclear about is what we want for the *major*
| >| >releases.  Do we just want them every 6 months?  Do we drive it by
| >| >quality?  If by quality, what are the quality criteria?  I suspect
| >| >
| >| We cannot drive it purely by quality, since we will never get quality
| >| unless we decide that we're going to make a release.  The level of
| >| bug-fixing activity goes up steeply as we approach a release: people
| >| start to fear that "their" platform/language/etc. will not work well.
| >| That's why we use a combination: drive by time, and then push for
| >| quality towards that date.
| > | | >| they can lead to lower quality, as more and more changes go
| > in,
| >| >| sometimes without corresponding problem-solving efforts.  I also don't
| >| >| think that "wait until it is ready" is a practical method for a
| >| >| project this big with this much change and with so much
| >| >| inter-dependency between components.
| >| >
| >| >Again, I agree.  However, because the project is that big, I believe
| >| >branching  proposals should meet consensus among developers.
| >| >
| >| In contrast, I don't see consensus as achievable in this group.  We
| >
| >That says a lot.
| >
| Note that I didn't say "cooperation"; I said "consensus", which means
| that everyone agrees.

No.  "everyone agrees" means "unanimity", and I consciously avoided
that term.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Mark Mitchell <mark@codesourcery.com> writes:
>| >
>| >| Gabriel Dos Reis wrote:
>| > | | >Making regular bug-fix releases at regularly spaced times makes
>| > good
>| >| >sense to me.  What I'm unclear about is what we want for the *major*
>| >| >releases.  Do we just want them every 6 months?  Do we drive it by
>| >| >quality?  If by quality, what are the quality criteria?  I suspect
>| >| >
>| >| We cannot drive it purely by quality, since we will never get quality
>| >| unless we decide that we're going to make a release.  The level of
>| >| bug-fixing activity goes up steeply as we approach a release: people
>| >| start to fear that "their" platform/language/etc. will not work well.
>| >| That's why we use a combination: drive by time, and then push for
>| >| quality towards that date.
>| > | | >| they can lead to lower quality, as more and more changes go
>| > in,
>| >| >| sometimes without corresponding problem-solving efforts.  I also don't
>| >| >| think that "wait until it is ready" is a practical method for a
>| >| >| project this big with this much change and with so much
>| >| >| inter-dependency between components.
>| >| >
>| >| >Again, I agree.  However, because the project is that big, I believe
>| >| >branching  proposals should meet consensus among developers.
>| >| >
>| >| In contrast, I don't see consensus as achievable in this group.  We
>| >
>| >That says a lot.
>| >
>| Note that I didn't say "cooperation"; I said "consensus", which means
>| that everyone agrees.
>
>No.  "everyone agrees" means "unanimity", and I consciously avoided
>that term.
>  
>
Well, since I didn't know what the word meant, then you shouldn't read 
too much into what I said. :-)

But I do think that our key stakeholders have very divergent 
objectives.  At the GCC summit, one person I respect told me we should 
do releases every two weeks; another I respect equally much recommended 
once a year.  I try to balance all the opinions to come up with a 
reasonable plan; to me, that's the "M" in "RM".  Unless the SC tells me 
otherwise, of course.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 04:00, Giovanni Bajo wrote:
> Mark Mitchell wrote:
> > Otherwise, I think we
> > proceed, and accept that the release will be useful to some people
> > and less useful to others.  (It will, for example, be useful to
> > people who need support for new targets, or want gfortran, or want
> > faster non-optimizing compile times, which we are now seeing for some
> > C++ programs.)
>
> As for C++ programs, I would like to remember that when tree-ssa was
> merged, there were big C++ compile time issues at -O0, which used to be in
> the merge requirement list, but were not met. There was agreement that
> these would be tackled after the merge, possibly by running a couple of
> cleanup optimization passes (DCE/CCP). I never heard of this project again
> since then, and the issues seems to have been forgotten.

The issue is not forgotten.  We've tried it and even just the
combination of DCE/CCP destroys too much of the original program
(e.g. user variables) for it to be debugable.


> I am sure I am not the only one who cares
> the only one who cares about C++ compilation times at -O0: we got
> substantially better with 3.4 (even wrt 2.95), but now we are regressing
> way too much.

I believe a lot of people care.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Giovanni Bajo]

Steven Bosscher wrote:

>> As for C++ programs, I would like to remember that when tree-ssa was
>> merged, there were big C++ compile time issues at -O0, which used to
>> be in the merge requirement list, but were not met. There was
>> agreement that these would be tackled after the merge, possibly by
>> running a couple of cleanup optimization passes (DCE/CCP). I never
>> heard of this project again since then, and the issues seems to have
>> been forgotten.
>
> The issue is not forgotten.  We've tried it and even just the
> combination of DCE/CCP destroys too much of the original program
> (e.g. user variables) for it to be debugable.

Thanks for the update. Do you think it is feasable to have a special version of
DCE/CCP (or a special flag in them) so that they don't destroy user variables,
to be used at -O0?

Giovanni Bajo

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 12:04, Giovanni Bajo wrote:
> Thanks for the update. Do you think it is feasable to have a special
> version of DCE/CCP (or a special flag in them) so that they don't destroy
> user variables, to be used at -O0?

We discussed that, yes.  You could look into how CCP propagates
things like addresses and so on, and figure out other things that
cause us to lose the user's variable.
DCE is not a real problem.  If CCP would just not turn so many
statements into dead code, it would work ;-)

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> On Monday 30 August 2004 12:04, Giovanni Bajo wrote:
> > Thanks for the update. Do you think it is feasable to have a special
> > version of DCE/CCP (or a special flag in them) so that they don't destroy
> > user variables, to be used at -O0?
> 
> We discussed that, yes.  You could look into how CCP propagates
> things like addresses and so on, and figure out other things that
> cause us to lose the user's variable.
> DCE is not a real problem.  If CCP would just not turn so many
> statements into dead code, it would work ;-)

I think all we need is to avoid CCP on user variables so user can change
their value and DCE killing whole statements so user can breakpoint.
Perhaps we can even consider idea of passing down the NOPs for
statements that have completely no effect.  This should be embeddable
into existing CCP/DCE code... perhaps ;)

Honza
> 
> Gr.
> Steven
> 

Re: GCC 3.5 Status (2004-08-29)

[Paolo Bonzini]

 > There was agreement that these would be
> tackled after the merge, possibly by running a couple of cleanup optimization
> passes (DCE/CCP).

CFG-transparent expansion did introduce a cleanup pass at -O0, because 
the cleanup that is done while the CFG is built, is now done at -O0 as 
well.  This is responsible of the -O0 3-4% speed increase brought in by 
CFG-transparent expansion.

Paolo

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 02:53, Mark Mitchell wrote:
> >Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
> >just about every project using GCC complaining about how GCC gets slower
> >with each release?
>
> Obviously, this is not ideal.  However, we have few practical
> alternatives.  I am not convinced that any further delay will get us
> better results.  I do not see a broad committment to improving
> compile-time speed when optimizing: in fact, I got zero proposals from
> people planning to work specifically on that issue.

It is funny that you say here that you got zero proposals, yet you
had a section in your mail:
> -------------------------
> Compile-Time Improvements
> -------------------------
> 
> There were three submissions relating primarily to compile-time

Also, I believe the edge-vector-branch work is also purely a speedup
project - it will make looking up PHI arguments much faster.  As I
have shown before on this mailing list, this is one of the major bottle
necks for passes like DOM.

Merging the LNO ivopts is another pass that could help win back speed
because it would allow us to kill the old loop optimizer (ie. loop.c 
and unroll.c) and all the yuckie-ness that it causes, like
reconstructing the CFG, recomputing dominance, recomputing loop info,
etc. etc.  All of that is expensive, and removing expensive things is
a good thing...

Anyway, you are probably right that there appear to be few people
working *specifically* on speeding up the compiler.  But many people
work on replacing expensive RTL optimizations with cheaper tree ones.


> Maintaining compilation speed was a precondition set by the SC for the
> tree-ssa merge.  If that condition was not met, then perhaps the merge
> should not have been performed.  The fact that it was probably indicates
> that people weren't too worried about these compile-time effects.

We discussed compile time back then and it was believed that we could
win back enough speed before stage3 to get back to around GCC 3.4 speeds,
which is IMO a good start.  After that, the Summit happened and suddenly
everyone was working on re-doing much of tree-ssa.  We're also slower
now than we were at the merge point.
So yes, in retrospect perhaps the merge did come too early.


> I continue to think it will take at least another several months to
> really get to the point where tree-ssa is unambiguously better
> (consistently better code, consistently better compile-times, fewer
> bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June,
> and SC approves, it's OK with me.

If we can restrict ourselves to the features proposed in your list,
and work on just getting those items ready, releasing GCC 3.5 later
would IMHO be much better than rushing it out in January.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 02:53, Mark Mitchell wrote:
>  
>
>>>Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
>>>just about every project using GCC complaining about how GCC gets slower
>>>with each release?
>>>      
>>>
>>Obviously, this is not ideal.  However, we have few practical
>>alternatives.  I am not convinced that any further delay will get us
>>better results.  I do not see a broad committment to improving
>>compile-time speed when optimizing: in fact, I got zero proposals from
>>people planning to work specifically on that issue.
>>    
>>
>
>It is funny that you say here that you got zero proposals, yet you
>had a section in your mail:
>  
>
I had zero proposals that described among their benefits compile-time 
speed *when optimizing*.  Perhaps Elliston's work will indeed help with 
that, but it wasn't called out seprately.  I'm all for that work on lots 
of levels, which is why when we were talking about projects we could 
trade for aliasing, I suggested hanging on to that one.

>Merging the LNO ivopts is another pass that could help win back speed
>because it would allow us to kill the old loop optimizer (ie. loop.c 
>and unroll.c) and all the yuckie-ness that it causes, like
>reconstructing the CFG, recomputing dominance, recomputing loop info,
>etc. etc.  All of that is expensive, and removing expensive things is
>a good thing...
>
>Anyway, you are probably right that there appear to be few people
>working *specifically* on speeding up the compiler.  But many people
>work on replacing expensive RTL optimizations with cheaper tree ones.
>  
>
Note that "merge LNO" is still on the plan, and I will be helping with 
that where I can.  Is the ivopts stuff already there,  or is it 
different?  If it is already there, then perhaps you should work on 
getting the old loop optimizer ready to die, so that we can do as you 
suggest above.  That might be a bigger, and easier to achieve, 
compile-time-when-optimizing improvement than Dan's stuff.

>>Maintaining compilation speed was a precondition set by the SC for the
>>tree-ssa merge.  If that condition was not met, then perhaps the merge
>>should not have been performed.  The fact that it was probably indicates
>>that people weren't too worried about these compile-time effects.
>>    
>>
>
>We discussed compile time back then and it was believed that we could
>win back enough speed before stage3 to get back to around GCC 3.4 speeds,
>which is IMO a good start.  After that, the Summit happened and suddenly
>everyone was working on re-doing much of tree-ssa.  We're also slower
>now than we were at the merge point.
>So yes, in retrospect perhaps the merge did come too early.
>  
>
It's water under the bridge in any case.  But, now, we have to decide 
what to do next.

>>I continue to think it will take at least another several months to
>>really get to the point where tree-ssa is unambiguously better
>>(consistently better code, consistently better compile-times, fewer
>>bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June,
>>and SC approves, it's OK with me.
>>    
>>
>
>If we can restrict ourselves to the features proposed in your list,
>and work on just getting those items ready, releasing GCC 3.5 later
>would IMHO be much better than rushing it out in January.
>  
>
I think it will be very hard to keep people from doing more stuff.  The 
argument is going to be "my thing is ready, and tested, and seems to 
help something, so why can't it go in?"  But each of those changes will 
introduce follow-on issues.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> On Monday 30 August 2004 02:53, Mark Mitchell wrote:
> > >Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
> > >just about every project using GCC complaining about how GCC gets slower
> > >with each release?
> >
> > Obviously, this is not ideal.  However, we have few practical
> > alternatives.  I am not convinced that any further delay will get us
> > better results.  I do not see a broad committment to improving
> > compile-time speed when optimizing: in fact, I got zero proposals from
> > people planning to work specifically on that issue.
> 
> It is funny that you say here that you got zero proposals, yet you
> had a section in your mail:
> > -------------------------
> > Compile-Time Improvements
> > -------------------------
> > 
> > There were three submissions relating primarily to compile-time
> 
> Also, I believe the edge-vector-branch work is also purely a speedup
> project - it will make looking up PHI arguments much faster.  As I
> have shown before on this mailing list, this is one of the major bottle
> necks for passes like DOM.
> 
> Merging the LNO ivopts is another pass that could help win back speed
> because it would allow us to kill the old loop optimizer (ie. loop.c 
> and unroll.c) and all the yuckie-ness that it causes, like
> reconstructing the CFG, recomputing dominance, recomputing loop info,
> etc. etc.  All of that is expensive, and removing expensive things is
> a good thing...
> 
> Anyway, you are probably right that there appear to be few people
> working *specifically* on speeding up the compiler.  But many people
> work on replacing expensive RTL optimizations with cheaper tree ones.

Also there are are certainly people (at least me ;) who seriously hope
to do some work before the code is frozen, but merging existing work is
a priority.  So I wrote only the tasks for whose I have something ready
with hope that I will also manage to figure out how to kill some of
perofmrance/memory problems on the way too.  I think number of these can
go to stage3 anyway.

Honza

Re: GCC 3.5 Status (2004-08-29)

[Jeffrey A Law]

On Mon, 2004-08-30 at 01:34, Steven Bosscher wrote:
> Also, I believe the edge-vector-branch work is also purely a speedup
> project - it will make looking up PHI arguments much faster.  As I
> have shown before on this mailing list, this is one of the major bottle
> necks for passes like DOM.
The edge-vector stuff is definitely a good thing.  However, I would
not expect a big benefit from it.

Yes, there are certain codes where it would speed up DOM in a 
meaningful way, but in general I don't expect you'll find that it's
a big improvement.  I like the edge-vector work because it means
we can rip out the hacks which we added to prevent the traversal
of the PHI arguments from becoming a huge time sink.

Speeding up DOM in the general case at this point means finding a
way to stop iteration.   Not surprisingly I've thought quite a bit
about that problem.

I haven't started any experiments, but my theory is that the cases
were iterating DOM is useful can be detected by the existence of
optimizable PHIs.

ie, if we have a degenerate PHI such as this after DOM

a1 = PHI (a0)   -- or
a1 = PHI (a0, a0) -- or
a1 = PHI (a0, a1)

Then iterating DOM may be useful.  I suspect (but certainly haven't
confirmed) that iterating if no such PHIs are found is relatively
pointless.

So we might be able to reduce iteration steps.  That would be good.
Again, I haven't played with this yet, so it's ripe for someone
to poke around.

Beyond that I've spent considerable time thinking about how to
remove the iteration step completely, but it's probably not
worth outlining those thoughts at the moment as they are
predicated on the concept that optimizable PHIs are the key to 
determining what (if anything) might be gained by iterating DOM.

Jeff

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

> >  I am confident that there
> > are alternatives that, while perhaps less comprehensive, get enough of
> > the common cases to achieve most of the benefits.
> 
> What is your confidence based on?  What common cases?  Did Dan tell you
> about the issues that he's fighting?  No "less comprehensive" solution
> exists that will not run into the exact same problems.
> 

I didn't tell him about the issues i'm fighting, so he's probably just
stating the typical result, ie "It takes less time to get the common
cases than it does to get all the cases".

Of course, the issues i'm dealing with are things that were punted on
earlier in the design of tree-ssa, because they were either hard to get
right, we didn't have time then, etc.

Let me give an example issue from an email i sent to diego and richard,
as a motivating example.

In our current scheme of things,

x = a.f
c = a.e
a.e = 5
c = a.f

becomes

VUSE (a_1)
x_2 = a.f

VUSE (a_1)
c_3 = a.e

a_4 = V_MAY_DEF (a_1)
a.e = 5

VUSE (a_4)
c_5 = a.f

As you can see, this type of VUSE should actually be called PARTIAL_USE
or something (it was the first use of vuse, before they were actually
used for memory operands, so i blame diego for not renaming it, unless
i'm misremembering and it was introduced at the same time as memory
operands).

Knowing that a.e doesn't actually kill a.f is the *easy* part.
It's representing this that is tricky.

You can't get rid of the VUSE of a, because it's still really a partial
use.  You can't simply change the V_MAY_DEF, because that will screw up
the later partial uses.  Unless we start to talk about fitting something
radically different into our scheme, you need to do something like add
an extra set of vuses so that it becomes:

VUSE (a_1)
VUSE (a.f_1)
x_2 = a.f

VUSE (a_1)
VUSE (a.e_1)
c_3 = a.e

a.e_2 = V_MAY_DEF (a.e_1)
a.e = 5

VUSE (a_1)
VUSE (a.f_1)
c_5 = a.f


This gives you the result you want.  But of course, we don't allow
component_refs in SSA_NAMES right now. You can't simply use field_decls,
because of compatible struct problems.

Do we want SSA_NAMES of component_refs here, or do we want just offset +
size, and then let the renamer do the work of figuring out the versions
to assign as a result:

IE

VUSE (a_1, 0, 4)
x_2 = a.f

VUSE (a_1, 4, 8)
c_3 = a.e

a_2 = V_MAY_DEF (a_1, 4, 8)
a.e = 5

VUSE (a_1, 0, 4)
c_5 = a.f

(IE let it figure out that we can still reuse a_1 here, because it
hasn't been def'd).

Or do we want something else entirely not involving vuses?

The issue of "p->a" and "p->b" aliasing hand a[0] vs a[1] aliasing have
similar unresolved design issues, like what do we put in the alias
bitmaps (IE pt_vars), since none of these things have uids that are in
the same namespace as variables. Or do i just ignore the existing alias
bitmaps -> may alias conversion, and just add component_refs to the
alias varrays directly, and maximally share the component refs.  Or
something else not involving component refs?  

This is the stuff i'm counting on taking the most time.
--Dan

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>>> I am confident that there
>>>are alternatives that, while perhaps less comprehensive, get enough of
>>>the common cases to achieve most of the benefits.
>>>      
>>>
>>What is your confidence based on?  What common cases?  Did Dan tell you
>>about the issues that he's fighting?  No "less comprehensive" solution
>>exists that will not run into the exact same problems.
>>
>>    
>>
>
>I didn't tell him about the issues i'm fighting, so he's probably just
>stating the typical result, ie "It takes less time to get the common
>cases than it does to get all the cases".
>
>Of course, the issues i'm dealing with are things that were punted on
>earlier in the design of tree-ssa, because they were either hard to get
>right, we didn't have time then, etc.
>
>Let me give an example issue from an email i sent to diego and richard,
>as a motivating example.
>  
>
Yes, there's some design work to be done.  That's why I believed your 
estimate about how long it will take, and why parallelizing the work 
will only help so much: you still have to agree on a design up front.

I still think there are likely to be expedient hacks that get you a lot 
of the win.  Note that the RTL optimizers didn't know about fields at 
all until recently (3.4?).  So, perhaps we can deal with the 
compile-time issue by accepting somewhat inferior generated code.  
Perhaps you can wait until SRA runs, and then just DTRT for objects that 
get SRA'd.  I don't have the answer; I'm just saying that there's likely 
to be one out there somewhere.  GCC got by for years with exactly this 
kind of solution, and actually managed to generate relatively decent 
code relatively often.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 03:12, Mark Mitchell wrote:
> Perhaps you can wait until SRA runs, and then just DTRT for objects that
> get SRA'd.

Alias structured are never SRA'd.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>  
>
>>Perhaps you can wait until SRA runs, and then just DTRT for objects that
>>get SRA'd.
>>    
>>
>
>Alias structured are never SRA'd.
>  
>
Certainly, in Dan's example:

x = a.f
c = a.e
a.e = 5
c = a.f

it should be possible to SRA "a" without any alias information at all, 
other than knowing that in C fields cannot overlap and that "a" is a 
struct, rather than a union.  I'm not saying that our implementation can 
do this; only that, it should be possible.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Mon, 30 Aug 2004, Mark Mitchell wrote:

> Steven Bosscher wrote:
>
>> On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>> 
>>> Perhaps you can wait until SRA runs, and then just DTRT for objects that
>>> get SRA'd.
>>> 
>> 
>> Alias structured are never SRA'd.
>> 
> Certainly, in Dan's example:
>
> x = a.f
> c = a.e
> a.e = 5
> c = a.f
>
> it should be possible to SRA "a" without any alias information at all,

Yes, you could, if you effectively ignored what the SSA infrastructure 
tells you (that they do overlap), and try to figure it out on your 
own.

This seems like a bad idea, IMHO.

--Dan

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>
>
> On Mon, 30 Aug 2004, Mark Mitchell wrote:
>
>> Steven Bosscher wrote:
>>
>>> On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>>>
>>>> Perhaps you can wait until SRA runs, and then just DTRT for objects 
>>>> that
>>>> get SRA'd.
>>>>
>>>
>>> Alias structured are never SRA'd.
>>>
>> Certainly, in Dan's example:
>>
>> x = a.f
>> c = a.e
>> a.e = 5
>> c = a.f
>>
>> it should be possible to SRA "a" without any alias information at all,
>
>
> Yes, you could, if you effectively ignored what the SSA infrastructure 
> tells you (that they do overlap), and try to figure it out on your own.
>
> This seems like a bad idea, IMHO.

In the abstract, yes.

However, sometimes it's appropriate to do something expedient to get 
from point A to point B.  As an example, the load-hoisting/store-sinking 
patch for the RTL optimizers was hardly a thing of beauty -- but did 
make a fair amount of code go quicker and wasn't responsible for very 
many bugs.  I'm glad it was in GCC -- and I'm glad that now we have real 
optimizers and can throw that stuff out!

I'm not arguing that we ought to do what I suggested; only that it's a 
possible alternative.  And that we should consider localized solutions 
(in this case, hacks to SRA, say) rather than just global solutions 
(change all representations for V_USE, adjust passes to understand 
that).  Sometimes one approach is better, sometimes the other, but both 
should be in play, especially if there is a big time/risk tradeoff.  (I 
have no idea how hard it would be to make SRA smarter; maybe there is no 
time win, in which case that suggestion is much weaker.)

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Sun, 2004-08-29 at 16:17 -0700, Mark Mitchell wrote:

Just a note, I pasted your email into the wiki
(www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
to ()'s so they don't show up as link, and making the data second level
list elements), so that we have a nice, editable html page you can use
to refer to.

http://www.dberlin.org/gccwiki/index.php/What%20will%20be%20in%203.5


It's also linked from the homepage.
People who add information about their projects on this list to the
wiki, please make sure you add a link from this page.

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>On Sun, 2004-08-29 at 16:17 -0700, Mark Mitchell wrote:
>
>Just a note, I pasted your email into the wiki
>(www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
>to ()'s so they don't show up as link, and making the data second level
>list elements), so that we have a nice, editable html page you can use
>to refer to.
>  
>
Thanks!

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Joseph S. Myers]

On Sun, 29 Aug 2004, Daniel Berlin wrote:

> Just a note, I pasted your email into the wiki
> (www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
> to ()'s so they don't show up as link, and making the data second level
> list elements), so that we have a nice, editable html page you can use
> to refer to.
> 
> http://www.dberlin.org/gccwiki/index.php/What%20will%20be%20in%203.5

The original call for projects - before it turned out there were 45 of 
them - suggested they'd go online as they came in.  Having people put 
their own proposals online (whether in the Wiki or in wwwdocs CVS) as part 
of submission seems like a plausible approach for future use to 
parallelise the process of putting the proposals online.

I've duly linked to the C90 status (including the original proposal) from 
the Wiki.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: GCC 3.5 Status (2004-08-29)

[Dorit Naishlos]

> If you disagree with my decisions, feel free to send me a message
> explaining why you think that the decision was inappropriate.  I will
> consider your position, but you will have to be convincing in order to
> change my mind.  To be convincing, make sure you quantify the win: it
> you want me to believe that your optimization is worthwhile tell me
> how much it improves a well-known benchmark.

> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
>
> ...
> * Vectorizer misaligned-loads support [Naishlos]

Let me try to convince you to change this decision:

1. Alignment is the number one limiting factor for vectorization on
mainline right now. Without this we can't vectorize anything that uses
pointers, for example. Together with the patches for unknown loop bound and
peeling for aligning a store (proposals that were accepted for 3.5), we
will be able to vectorize loops of the following (very basic and very
common) form:
   "while (--n) *q++ = *a++ + *b++".

2. Risk-free. It is entirely encapsulated within -ftree-vectorize which is
disabled by default (so no risks if not explicitly enabled).

3. Chances of meeting deadline - yes, Sept. 19 is aggressive. But note that
we already had this functionality implemented completely on the
apple-ppc-branch a couple of months ago, but using target builtins instead
of new tree-codes. Introducing the new tree-codes indeed takes some time,
but it may be doable by September 19th, considering the fast progress made
together with Richard. Given the huge benefit and zero risk, I think it's
worth while to give it a chance. What do you say?

thanks,
dorit

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Dorit Naishlos wrote:

>>If you disagree with my decisions, feel free to send me a message
>>explaining why you think that the decision was inappropriate.  I will
>>consider your position, but you will have to be convincing in order to
>>change my mind.  To be convincing, make sure you quantify the win: it
>>you want me to believe that your optimization is worthwhile tell me
>>how much it improves a well-known benchmark.
>>    
>>
>
>  
>
>>The following changes will be postponed until GCC 3.6.  These changes
>>either provide too little benefit, are too risky, or will take too
>>much time to complete.
>>
>>...
>>* Vectorizer misaligned-loads support [Naishlos]
>>    
>>
>
>Let me try to convince you to change this decision:
>
>1. Alignment is the number one limiting factor for vectorization on
>mainline right now. Without this we can't vectorize anything that uses
>pointers, for example. Together with the patches for unknown loop bound and
>peeling for aligning a store (proposals that were accepted for 3.5), we
>will be able to vectorize loops of the following (very basic and very
>common) form:
>   "while (--n) *q++ = *a++ + *b++".
>
>2. Risk-free. It is entirely encapsulated within -ftree-vectorize which is
>disabled by default (so no risks if not explicitly enabled).
>  
>
I disagree.  The risk is that it will break -ftree-vectorize, making 
this valuable new feature less useful.

Let's do the other things first.  If you get it all wrapped up in a nice 
neat package with a nice neat bow, we can reconsider.  :-)

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
> 

> 
> * Tree-based coverage [Hubicka]

Perhaps I should note that current RTL based coverage is now broken in
several interesting ways.  I will see what can I do on both fronts
(putting things together to get tree coverage finished, perhaps disabled
by default, and try to fix the SSA optimizers to not mess up the CFG
structure too badly for RTL coverge) after finishing the other two
projects.

Honza
> 
> * Aliasing improvements for structure fields [Berlin]
> 
> * Value range propagation [Novillo]
> 
> * CFG-based inliner [Hastings]
> 
> * Vectorizer misaligned-loads support [Naishlos]
> 
> * Vectorizer pattern recognition support [Naishlos]
> 
> * If-conversion and vectorization of conditional code [Patel]
> 
> * SMS improvements [Hagog, Markovitch]

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Jan Hubicka wrote:

>>-- 
>>Mark Mitchell
>>CodeSourcery, LLC
>>(916) 791-8304
>>mark@codesourcery.com
>>
>>    
>>
>
>  
>
>>* Tree-based coverage [Hubicka]
>>    
>>
>
>Perhaps I should note that current RTL based coverage is now broken in
>several interesting ways.  
>
I did understand that from your original project proposal, but thank you 
for the reminder.  I understand that problem, but I don't see it as a 
must-have for a release.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> >>-- 
> >>Mark Mitchell
> >>CodeSourcery, LLC
> >>(916) 791-8304
> >>mark@codesourcery.com
> >>
> >>   
> >>
> >
> > 
> >
> >>* Tree-based coverage [Hubicka]
> >>   
> >>
> >
> >Perhaps I should note that current RTL based coverage is now broken in
> >several interesting ways.  
> >
> I did understand that from your original project proposal, but thank you 
> for the reminder.  I understand that problem, but I don't see it as a 
> must-have for a release.

me neither, so lets see how things will shape up in next few weeks.
There are definitly more important things to do.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com

Re: GCC 3.5 Status (2004-08-29)

[Diego Novillo]

Mark has taken enough beating for the 3.5 schedule, but I think his plan
is very reasonable and I fully support it.  We are currently overloaded
with new features and we need to take a breather and start stabilizing
what we have.

$NEXTRELEASE will probably not be perfect, but $NEXTRELEASE + 1 will be
pretty good and $NEXTRELEASE + 2 will be even better.


Diego.

Re: GCC 3.5 Status (2004-08-29)

[Devang Patel]

On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:

> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
>
> [snip]

> * If-conversion and vectorization of conditional code [Patel]

Two points:

1) Benefit of this work (along with Dorit's work):

	http://gcc.gnu.org/ml/gcc/2003-07/msg01355.html

2) It is implemented once entirely in apple-ppc-branch. If-conversion 
patch is being reviewed by Richard. Today I was offline so I have not 
replied his email, but I am confident that it will be OKed soon. 
Regarding second part, it requires replacing builtins with new tree 
codes. Richard and Jim explained lot of things and I'll try hard to 
complete it by deliver date.

-
Devang