Re: GIMPLE tuples document uploaded to wiki
Daniel Berlin wrote on 04/14/07 22:59: > If there was stmt->aux we'd put it there instead (note that the > current way wastes memory, since we really only care about UID's for > statements that generate vdefs/vuses) That's the thing. There currently is *no* "aux" field to do this. We may be forced to add one, but for now tuples have no room for auxiliary information like this.
Re: GIMPLE tuples document uploaded to wiki
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote on 04/14/07 22:59: > If there was stmt->aux we'd put it there instead (note that the > current way wastes memory, since we really only care about UID's for > statements that generate vdefs/vuses) That's the thing. There currently is *no* "aux" field to do this. We may be forced to add one, but for now tuples have no room for auxiliary information like this. For PRE, having a hashtable for statement uids will probably not slow things down too much. For the expression ids, it will probably noticeably slow us down, but i'll check.
Re: Call to arms: testsuite failures on various targets
> * hppa64-hp-hpux11.11: many failures Most of these are "Type/rank mismatch in argument": FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E rror: Type/rank mismatch in argument 'charr' at (1) /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:23: E rror: Type/rank mismatch in argument 'charr' at (1) In gfortran.dg/entry_1.f90: Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:15: Error: Type/rank mis match in argument 'p' at (1) /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:16: Error: Type/rank mis match in argument 'p' at (1) /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/entry_1.f90:40: Fatal Error: Can't o pen module file 'm.mod' for reading at (1): No such file or directory Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Call to arms: testsuite failures on various targets
Thanks Tim for sending the dump files!
> for this one:
> > FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vectorized 1 loops 1
>
> there should be { target vect_unpack } added to the check. i.e.:
> - /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
*/
> + /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"
> { target vect_unpack } } } */
>
> for the rest:
>
> > FAIL: gcc.dg/vect/vect-iv-4.c scan-tree-dump-times vectorized 1 loops 1
this one is missing { target vect_pack_mod }
> > FAIL: gcc.dg/vect/vect-iv-9.c scan-tree-dump-times vectorized 1 loops 2
this one missing { target vect_int_mult }
> > FAIL: gcc.dg/vect/vect-reduc-dot-s16b.c scan-tree-dump-times
> > vectorized 1 loops 0
here we need to add ia64 to the list of targets in
'vect_widen_sum_hi_to_si' in target-support.exp
> > FAIL: gcc.dg/vect/vect-reduc-dot-u16b.c scan-tree-dump-times
> > vectorized 1 loops 1
missing { target vect_pack_mod } again
> > FAIL: gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times
> > vectorized 1 loops 0
add ia64 to 'vect_widen_sum_hi_to_si' in target-support.exp
> > FAIL: gcc.dg/vect/vect-reduc-pattern-1c.c scan-tree-dump-times
> > vectorized 1 loops 0
add ia64 to 'vect_widen_sum_qi_to_hi' in target-support.exp
> > FAIL: gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times
> > vectorized 1 loops 0
add ia64 to 'vect_widen_sum_hi_to_si' in target-support.exp
> > FAIL: gcc.dg/vect/vect-widen-mult-u16.c scan-tree-dump-times
> > vectorized 1 loops 1
missing { target vect_pack_mod }
> > FAIL: gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c scan-tree-dump-times
> > vectorized 1 loops 0
add ia64 to 'vect_widen_sum_qi_to_hi' in target-support.exp
> > FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times
> > Alignment of access forced using peeling 3
> >
>
For this one - can you please send the dump file generated with
-fdump-tree-vect-details? (the files you sent did not contain the detailed
dump info). Specifically, on powerpc I see this:
Created dr for tmp1[2].e.n[1][i_79][j_68]
base_address: &tmp1
offset from base address: () (i_79 * 32)
constant offset from base address: 10544
base_object: tmp1[2].e.n
step: 4B
misalignment from base: 10544B
aligned to: 8
memtag: tmp1
...
/Develop/autovect-dn/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:69:
note: === vect_analyze_data_refs_alignment ===
/Develop/autovect-dn/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:69:
note: vect_compute_data_ref_alignment:
/Develop/autovect-dn/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:69:
note: Unknown alignment for access: tmp1
...
/Develop/autovect-dn/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:69:
note: Alignment of access forced using peeling.
/Develop/autovect-dn/gcc/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-69.c:69:
note: Peeling for alignment will be applied.
I'd like to compare that to what you get on ia64.
In the meantime - this patch includes the above suggested fixes for the
rest of the tests (tested on the vectorizer testcases on i686-pc-linux-gnu
and powerpc-linux, but really need to be tested on ia64):
dorit
(See attached file: ia64fixes.txt)
> I'll need to look closer. Could you please send me (offline) the .
> vect dump files (with -fdump-tree-vect-details) for these?
>
> thanks,
> dorit
>
>
> > === gcc Summary ===
> >
> > # of expected passes 42231
> > # of unexpected failures 23
> > # of unexpected successes 2
> > # of expected failures 155
> > # of unresolved testcases 2
> > # of untested testcases 28
> > # of unsupported tests 374
> > /home/tim/src/gcc-4.3-20070413/ia64/gcc/xgcc version 4.3.0 20070413
> > (experimental)
> >
> > === gfortran tests ===
> >
> >
> > Running target unix
> >
> > === gfortran Summary ===
> >
> > # of expected passes 17438
> > # of expected failures 13
> > # of unsupported tests 20
> > /home/tim/src/gcc-4.3-20070413/ia64/gcc/testsuite/gfortran/../..
> > /gfortran version 4.3.0 20070413 (experimental)
> >
> > === g++ tests ===
> >
> >
> > Running target unix
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect
> > call -> direct call.* AA transformation on insn
> > FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dum
Maintainers for C preprocessor
The GCC SC has been considering the issue of maintainers for the C/C++ preprocessor, and has: 1. Appointed Tom Tromey as a non-algorithmic maintainer for the preprocessor. Congratulations, Tom! 2. Appointed the C and C++ maintainers as co-maintainers of the preprocessor. This appointment is not personal; rather, it is intended to indicate that, at any given point in time, any C/C++ maintainer is also a preprocessor maintainer. In short, the decision is to consider the preprocessor a component of the C and C++ front ends, from a maintenance perspective. Tom, please update the MAINTAINERS file to reflect your new appointment, and thank you for agreeing to take on this responsibility! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: error: "no newline at end of file"
Manuel López-Ibáñez wrote: > Then, if the warnings are not very useful but are mandated by the > standard, I think that the sensible thing is to make them conditional > on -pedantic. This way, people wanting strict diagnostics for > nonconformant code can get them, while people that don't care about it > don't need to suffer even a warning. I agree. For diagnostics for issues which (a) probably do not indicate mistakes on the part of the programmer, and (b) can be readily ignored by the compiler, the idiomatic handling is: if (pedantic) pedwarn (...); Thus, only users who want pedantic error messages see the message. They can control whether the message is an error or a warning via -pedantic-errors (or the C++ front-end's -fpermissive). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Status of PR21561
If you try ../gcc-4.1.2/configure; make bootstrap on a powerpc-darwin G4 system, then the bootstrap will fail because the process builds 64-bit multilibs and tries to execute a program with "xgcc -m64'. In May 2005, PR 21561 reported this same problem on 32-bit x86 solaris; the workaround is to specify --disable-multilibs on the configure line. The suggested fix is to automatically generate this "--disable-multilibs" on machines where bootstrap would fail without it. A comment in the PR says "Supending until the other bugs like this is fixed." I'm kind of surprised that a bootstrap failure like this was shipped with 4.1.2; also, I couldn't find out using bugzilla what are "the other bugs like this". Would it be reasonable to reopen this report? A bootstrap failure on 32-bit powerpc-darwin is definitely a regression from gcc-3. Brad
Re: Status of PR21561
On 4/15/07, Bradley Lucier <[EMAIL PROTECTED]> wrote: If you try ../gcc-4.1.2/configure; make bootstrap on a powerpc-darwin G4 system, then the bootstrap will fail because the process builds 64-bit multilibs and tries to execute a program with "xgcc -m64'. Again this is not magic or rock science, use --disable-mutlilib for 32bit targets that enable 64bit by default even on machines where you have only run 32bit programs. I think this has already been fixed on the trunk but I cannot test it because I don't have access to a darwin machine that I want to bootstrap on or one with internet access. There is no magic anyways, it was an automake/libtool bug anyways :) and not a GCC one :). -- Pinski
Re: Status of PR21561
On Apr 15, 2007, at 6:37 PM, Andrew Pinski wrote: On 4/15/07, Bradley Lucier <[EMAIL PROTECTED]> wrote: If you try ../gcc-4.1.2/configure; make bootstrap on a powerpc-darwin G4 system, then the bootstrap will fail because the process builds 64-bit multilibs and tries to execute a program with "xgcc -m64'. Again this is not magic or rock science, use --disable-mutlilib for 32bit targets that enable 64bit by default even on machines where you have only run 32bit programs. After my first two attempts today to build 4.1.2 on powerpc-darwin failed, I'm already trying this. I put a note in the PR21561 saying I think it should be re-opened. Brad
GCC 4.2.0 Status Report (2007-04-15)
As has been remarked on the GCC mailing lists, I've not succeeded in getting GCC 4.2.0 out the door. However, with the limited criteria that we target only P1 regressions not present in 4.1.x, we seem to be getting a bit closer. The only regressions in this category are: 26792 [4.2 Regression] need to use autoconf when using newly-ad... 29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap 30222 [4.2 Regression] gcc.target/i386/vectorize1.c ICEs 30700 [4.2 Regression] YA bogus undefined reference error to st... 31136 [4.2 Regression] FRE ignores bit-field truncation (C and ... 31360 [4.2/4.3 Regression] rtl loop invariant is broken 31513 [4.2/4.3 Regression] Miscompilation of Function Passing B... I'm disappointed that the patch for PR 30700 hasn't been applied to the 4.2 branch; according to bugzilla it looks like all that's needed is a build/test cycle there. I'll be tackling 31513 tonight. Perhaps I can get to one or two of the other PRs above. The broader question of why there are so many 124 P3 or higher regressions against 4.2.0 points to a more fundamental problem. Despite the fact that virtually all of the bugs open against 4.2.0 are also open against 4.1 or 4.3 -- or both! -- there seems to be little interest in fixing them. Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done. I've considered that, but I don't think it's a good idea. In practice, this whole software freedom thing means that people can go off and do things on their own anyhow; people who are more motivated to add features than fix bugs are likely just to keep doing that, and wait for mainline to reopen. However, I would consider asking the SC for permission to institute a rule that would prevent contributors responsible for P1 bugs (in the only possible bright-line sense: that the bug appeared as a result of their patch) from checking in changes on mainline until the P1 bug was resolved. This would provide an individual incentive for each of us to clean up our own mess. I'm certain that someone will raise the "latent bug" issue, but that's not the common case. And, we can always decide to make an exception if necessary. Of course, if we do this, I'd be happy to recuse myself as necessary, in order to avoid any appearance of favoritism towards CodeSourcery personnel. What do people think of that suggestion? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: GCC 4.2.0 Status Report (2007-04-15)
On 15 April 2007 23:51, Mark Mitchell wrote: > The broader question of why there are so many 124 P3 or higher > regressions against 4.2.0 points to a more fundamental problem. > Despite the fact that virtually all of the bugs open against 4.2.0 are > also open against 4.1 or 4.3 -- or both! -- there seems to be little > interest in fixing them. > > Some have suggested that I try to solve this by closing GCC 4.3 > development until 4.2.0 is done. I've considered that, but I don't > think it's a good idea. In practice, this whole software freedom thing > means that people can go off and do things on their own anyhow; people > who are more motivated to add features than fix bugs are likely just to > keep doing that, and wait for mainline to reopen. So here's a second possibility: delete the 4.2 branch, and start again with a fresh release branch. Call it 4.2 again, although it would be more-or-less what we're expecting to be 4.3. Maybe it would be not just simplest but also most effective to cut our losses and try again. > However, I would consider asking the SC for permission to institute a > rule that would prevent contributors responsible for P1 bugs (in the > only possible bright-line sense: that the bug appeared as a result of > their patch) from checking in changes on mainline until the P1 bug was > resolved. This would provide an individual incentive for each of us to > clean up our own mess. I'm certain that someone will raise the "latent > bug" issue, but that's not the common case. And, we can always decide > to make an exception if necessary. Of course, if we do this, I'd be > happy to recuse myself as necessary, in order to avoid any appearance of > favoritism towards CodeSourcery personnel. > > What do people think of that suggestion? I think it runs the risk of seeming finger-pointy and causing political reactions, but I wouldn't object to it as a new working practice. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.2.0 Status Report (2007-04-15)
Dave Korn wrote: >> Some have suggested that I try to solve this by closing GCC 4.3 >> development until 4.2.0 is done. I've considered that, but I don't >> think it's a good idea. In practice, this whole software freedom thing >> means that people can go off and do things on their own anyhow; people >> who are more motivated to add features than fix bugs are likely just to >> keep doing that, and wait for mainline to reopen. > > So here's a second possibility: delete the 4.2 branch, and start again with > a fresh release branch. Call it 4.2 again, although it would be more-or-less > what we're expecting to be 4.3. Maybe it would be not just simplest but also > most effective to cut our losses and try again. I've already considered, discussed, and dismissed this possibility -- and I still think it's a bad idea for all the same reasons. See: http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html for my thinking. Of course, this bit: > Then, we'll have a 4.2.0 release by (worst case, and allowing for > lameness on my part) March 31. has not come to pass. Either I did not allow for sufficient lameness on my part, or I failed to correctly estimate the worst case, or both. :-( I also see no evidence that 4.3 is going to be particularly better. After all, most of the 4.2 bugs are still in 4.3, so there's certainly no reason to think that a new branch today would be any closer to release. And there's a good bit more functionality that we want to get into 4.3, which, in the way of things, is likely to introduce new bugs, no matter how positive its overall impact. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: GCC 4.2.0 Status Report (2007-04-15)
> > Despite the fact that virtually all of the bugs open against 4.2.0 are > > also open against 4.1 or 4.3 -- or both! -- there seems to be little > > interest in fixing them. > > > > Some have suggested that I try to solve this by closing GCC 4.3 > > development until 4.2.0 is done. > > So here's a second possibility: delete the 4.2 branch, and start again with > a fresh release branch. Call it 4.2 again, although it would be more-or-less > what we're expecting to be 4.3. Maybe it would be not just simplest but also > most effective to cut our losses and try again. This is a really bad idea. 4.3 is months from being ready to release and there's only a handful of P1 PRs blocking 4.2 from release. From my perspective, 4.2 is better than 4.1 in many ways. As a port maintainer, I have spent a large amount of time trying to ensure that 4.2 is ready. I'd be quite upset if this effort was for naught. If 4.2 has deficiencies that need addressing prior to release, then the specific technical aspects need to be discussed. A general suggestion that the branch be deleted isn't acceptable as the same mistakes will be made all over again. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: GCC 4.2.0 Status Report (2007-04-15)
On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: As has been remarked on the GCC mailing lists, I've not succeeded in getting GCC 4.2.0 out the door. However, with the limited criteria that we target only P1 regressions not present in 4.1.x, we seem to be getting a bit closer. The only regressions in this category are: 26792 [4.2 Regression] need to use autoconf when using newly-ad... 29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap 30222 [4.2 Regression] gcc.target/i386/vectorize1.c ICEs 30700 [4.2 Regression] YA bogus undefined reference error to st... 31136 [4.2 Regression] FRE ignores bit-field truncation (C and ... 31360 [4.2/4.3 Regression] rtl loop invariant is broken 31513 [4.2/4.3 Regression] Miscompilation of Function Passing B... I'm disappointed that the patch for PR 30700 hasn't been applied to the 4.2 branch; according to bugzilla it looks like all that's needed is a build/test cycle there. I'll be tackling 31513 tonight. Perhaps I can get to one or two of the other PRs above. The broader question of why there are so many 124 P3 or higher regressions against 4.2.0 points to a more fundamental problem. Despite the fact that virtually all of the bugs open against 4.2.0 are also open against 4.1 or 4.3 -- or both! -- there seems to be little interest in fixing them. Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done. I've considered that, but I don't think it's a good idea. In practice, this whole software freedom thing means that people can go off and do things on their own anyhow; people who are more motivated to add features than fix bugs are likely just to keep doing that, and wait for mainline to reopen. This is certainly what I would do. I fixed all the critical 4.2 bugs I was responsible for. I have no plans to fix the non-critical ones because to be honest, 4.2 lacks a lot of the infrastructure to fix them in sane ways. However, I would consider asking the SC for permission to institute a rule that would prevent contributors responsible for P1 bugs (in the only possible bright-line sense: that the bug appeared as a result of their patch) from checking in changes on mainline until the P1 bug was resolved. This would provide an individual incentive for each of us to clean up our own mess. And how exactly would we plan on tracking this? At least to me, it seems like adding more administrative overhead and i don't see it fixing the underlying problem. You want more bugs fixed, it would seem a better way would be to build a better sense of community (Have bugfix-only days, etc) and encourage it through good behavior, not through negative reinforcement. You can't fix behavior in a volunteer community by beating people into submission. There will always be those who don't get it, or who everyone believes isn't doing a good job, and it's not just because they are committing patches and leaving messes. The reality is we just don't want people like this in our community, and they shouldn't have write access, TBQH[1]. This is not to say we shouldn't accept/review their patches and commit them for them. But with write access comes a level of trust. --Dan [1] Then again, I think our system of granting more than write-after-approval access based on the secret discussions of a bunch of people, some of whom don't even work on gcc anymore, is flawed anyway, so take it for what it's worth . It's really not a dig against the SC as people, most are great people. As an entity, I don't believe this should be in it's job description. I firmly believe the decision of who gets write access should be in the hands of the committers, since those are whom are most affected, and those who are continually active.
Re: GCC 4.2.0 Status Report (2007-04-15)
Daniel Berlin wrote: On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: However, I would consider asking the SC for permission to institute a rule that would prevent contributors responsible for P1 bugs (in the only possible bright-line sense: that the bug appeared as a result of their patch) from checking in changes on mainline until the P1 bug was resolved. This would provide an individual incentive for each of us to clean up our own mess. And how exactly would we plan on tracking this? At least to me, it seems like adding more administrative overhead and i don't see it fixing the underlying problem. You want more bugs fixed, it would seem a better way would be to build a better sense of community (Have bugfix-only days, etc) and encourage it through good behavior, not through negative reinforcement. You can't fix behavior in a volunteer community by beating people into submission. There will always be those who don't get it, or who everyone believes isn't doing a good job, and it's not just because they are committing patches and leaving messes. The reality is we just don't want people like this in our community, and they shouldn't have write access, TBQH[1]. It seems to me that having the support infrastructure for this would potentially be quite useful. However, I agree with Daniel that I'm not so sure how much actually having the policy on top of that will help. We have 124 regression PRs of P3 or above against 4.2.0, and 7 of P1. For how many of those do we know which commit caused the regression? My personal feeling is that it's entirely possible that I might make a mistake in some code that doesn't show up in the regression testing and nobody notices in the code review, and a P1 regression might come out of that mistake a few months later when someone notices the consequences. I hope this won't happen, and I try hard to keep it from happening, and we've got a lot of process in place to try to prevent it, but with the number of commits we have, statistical anomalies will happen. At that point, if I don't see the bug report (or don't recognize that it's a consequence of my code when I'm looking at the list of regressions), then I'll have no idea that I'm responsible for it. However, if we had some sort of infrastructure in place that would produce a message to me saying "Your commit number #123456 introduced this P1 regression", I'm likely going to say, "Oh, bother," and do my best to fix it. I suspect that the people who had the poor luck to cause the PRs on Mark's current hit list would feel exactly the same way. Also, beyond that, I would strongly suspect that these PRs haven't been fixed in large part because they're difficult to track down, and possibly if we knew what commit had introduced them, we'd be a good bit farther along in fixing them, even without having the help of whoever introduced them. This is, after all, a large part of why we try to have the "one idea per patch" rule. - Brooks, who is also wondering who'd get to decide whether a regression qualified as a P1 under this proposal
RE: GCC 4.2.0 Status Report (2007-04-15)
> -Original Message- > From: Mark Mitchell [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 15, 2007 4:51 PM > To: GCC > Subject: GCC 4.2.0 Status Report (2007-04-15) > > However, I would consider asking the SC for permission to institute a > rule that would prevent contributors responsible for P1 bugs (in the > only possible bright-line sense: that the bug appeared as a result of > their patch) from checking in changes on mainline until the P1 bug was > resolved. This would provide an individual incentive for > each of us to > clean up our own mess. I'm certain that someone will raise > the "latent > bug" issue, but that's not the common case. And, we can always decide > to make an exception if necessary. Of course, if we do this, I'd be > happy to recuse myself as necessary, in order to avoid any > appearance of > favoritism towards CodeSourcery personnel. > > What do people think of that suggestion? Instead of creating a new rule to try to convince people to get things done, why not use your role of release manager and just not allow a release of 4.2 or 4.3 until the quality is deemed sufficient. If it takes longer to do a release then so be it. Politely point out what is left to get done. The status reports are a helpful reminder of the state of the branch. Eric Weddington
