This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFC: Ensure TREE_TYPE (TYPE_MIN_VALUE (t)) == t


On 27 Apr 2007 16:00:08 -0700, Ian Lance Taylor <iant@google.com> wrote:
> And I still say the overflow patch in VRP should not (I repeat should
> not) have been committed this late, if you look at all the fall out,
> 4.2 is going to be worse now than ever before.

I assume that by fall out you mean the bug reports which I have fixed?
Yes and 4.2 is about to be frozen on Sunday and the recent fall out
shows that this patch was tested as much as it could be with the
current GCC testsuite but looking back, it should have more tested on
than the testsuite because it is late in the game

We have had this fight, and it has been decided.  I never argued that
the overflow patch was an unalloyed good; it was merely, in my
opinion, the best of a set of poor choices.  Please stop trying to
reopen the fight.  That serves no useful purpose.

I am not trying to say it is not good or even the best of a set of choices if we take out the timming issue. The timming issue is what I am saying is wrong here and nothing else. If we were another 3 months out for the release (which is a bad thing), then I would not have a problem but now we are two weeks away and adding more hacks to fix up something which was timed wrong in the first place is just wrong.

At the very least, please say which alternative negative consequence you would have
preferred.
There is no negative consequences if people actually know and
understand the language they are writting in, GCC is not supposed to
be a teacher of computer languages, it can help but it can never be a
complete solution for reading manuals (yes people don't read manuals
but maybe it is better for those to stop programming).

I am saying this for all patches, just this was the biggest patch
which went in during the stage3 of 4.2.  Look at it another way, the
patch is good but poorly timed and big for the timining that it went
in.  Trade offs are needed and we are trading off a good extra feature
for unknown unstablity that was added in the last minute.  I don't
know but I would rather have more known stablity of the compiler than
extra features so do my custumors.

This is not a knock on your work, just the timmings of the work.  If
this was originally developed on a branch, there would be a real
critial for merging it.  Putting new features into the compiler at
stage3 just means two things, we are more prone to bugs which has been
shown already but the 4 or so bug reports for this feature.  We are
getting down to the wire on getting 4.2 released, I would recommend
(and I am saying this in general), if a patch committed during stage3
causes a regression during these last days, we should look at the
patch again and decide if we really want it in 4.2 or not.  I think
this should apply for all of stage3 and not just the last week.

We already have a policy (which gets violated all the time) about not
committing new features during stage3.  The reason behind this policy
is to get the compiler to a point where we can release it without much
unknown unstability.  If this policy is going to be violated all the
time, then we either should get rid of it or decide how we do our
releases because right now the releasing of GCC is broken and putting
new features during stage3 is just making it worse.

Again, I am not discrediting your work, just the timming of placing
stuff on a release branch.

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]