Re: GCC 4.3 target deprecation proposals
Hi Joseph, I have posted some results for the xstormy16-elf target. They are not great (614 failures) but I do hope that this can target can be removed from the potential deprecations list. Cheers Nick
Re: Seperate the c front-end from GCC
Hello, > I have to use gcc's C parser and the intermediate representation, so that I > can manipulate the basic blocks and CFG. So I need to plug out the parser > and the intermediate code. I would like to know if it is possible to plug > out the parser and the intermediate representation code. this sound, as if you do not need the rest of gcc ... so just need a parser and an appropriate intermediate representation. Maybe you should have a look at LLVM (www.llvm.org) in combination with clang (clang.llvm.org). Ciao, Fabian
Re: dwarf2 EH address size
DJ Delorie <[EMAIL PROTECTED]> writes: > > The EH code does seem to use POINTER_SIZE pretty consistently. > > DWARF2_ADDR_SIZE is for the debug info, not the exception frame > > info. I haven't looked into the history of why this is so. > > Hmmm... I suppose the EH info is used by the runtime as well, right? > So changing to a non-standard addr size complicates the unwinder. Certainly if you use DW_EH_PE_absptr the compiler, the unwinder library, and the binutils all must agree on the size that that means. On the other hand, if you define ASM_PREFERRED_EH_DATA_FORMAT the encoding will be recorded in the FDE and CIE, and there will be no possible confusion by any tool. I actually think that is normally the best choice, especially for a target for which confusion is possible. Lots of targets define ASM_PREFERRED_EH_DATA_FORMAT, it's not unusual. Ian
Re: uninit-13 testcase: Weird line number in the "uninitialized use" warning
"Andreas Krebbel" <[EMAIL PROTECTED]> writes: > Should we do something about this for GCC 4.3 or just XFAIL the > testcases for s390 and s390x? I haven't tried to figure out what is really going on, but I know the answer to this question: an off-by-one error in the line number for a warning is a minor issue, and is not worth fixing for 4.3 at this stage. Ian
Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code
On 25 Jan 2008, at 6:11 PM, Michael Witten wrote: On 25 Jan 2008, at 8:16 AM, Michael Witten wrote: On 24 Jan 2008, at 7:20 AM, Brian Dessent wrote: Michael Witten wrote: Can I build gcc in this way? I've been trying for quite some time now to achieve such a stripped down gcc, but it would seem that the gcc build process insists on building these libraries, which I think is wholly unnecessary. You might be able to approximate this by "make all-gcc" and then "make install-gcc" (or just manually copying the xgcc to the destination.) I'm a little uncomfortable just taking the xgcc that's left over when the build fails. I apologize. For some reason, when I tried make all-gcc the build failed. Aha! Apparently the build DOES FAIL when building on Mac OS X 10.5 (darwin 9.1.0) for the PowerPC (there is no problem with the x86 version): cc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- variadic-macros -Wold-style-definition -Wmissing-format-attribute- DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/ gcc/../include -I../../src/gcc/../libcpp/include -I. -I. -I../../ src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/ gcc/../libcpp/include ../../src/gcc/config/rs6000/host-darwin.c -o host-ppc-darwin.o ../../src/gcc/config/rs6000/host-darwin.c:38: warning: ‘struct sigaltstack’ declared inside parameter list ../../src/gcc/config/rs6000/host-darwin.c:38: warning: its scope is only this definition or declaration, which is probably not what you want ../../src/gcc/config/rs6000/host-darwin.c:38: error: conflicting types for ‘sigaltstack’ /usr/include/signal.h:89: error: previous declaration of ‘sigaltstack’ was here ../../src/gcc/config/rs6000/host-darwin.c: In function ‘segv_handler’: ../../src/gcc/config/rs6000/host-darwin.c:71: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘es’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c: In function ‘darwin_rs6000_extra_signals’: ../../src/gcc/config/rs6000/host-darwin.c:134: warning: passing argument 1 of ‘sigaltstack’ from incompatible pointer type make[1]: *** [host-ppc-darwin.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [all-gcc] Error 2 It can be compiled thusly: MACOSX_DEPLOYMENT_TARGET=10.4 make all-gcc
UNIQUE ID (INSN UID) Question
Hello Everyone, I have a quick question regarding instruction unique ID in the RTL. Is this number unique for the function? or is it unique for the entire program that it is compiling? I would like to "mark" instructions and identify them, so can I use this value as a unique identifier for program level? Any help or suggestion is highly appreciated. Thanks, Balaji V. Iyer. -- Balaji V. Iyer PhD Student, Center for Efficient, Scalable and Reliable Computing, Department of Electrical and Computer Engineering, North Carolina State University. -- Balaji V. Iyer PhD Student, Center for Efficient, Scalable and Reliable Computing, Department of Electrical and Computer Engineering, North Carolina State University.
Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:
On 22/01/2008, Christian Joensson wrote: > 2008/1/21, Jonathan Wakely > > My first guess would be that you've somehow got the C++0x and TR1 > > versions of boost_sp_shared_count.h mixed up and you're including the > > wrong one. > > well, the testsuite results are posted at, e.g., > > http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00956.html > > and the libstdc++.log file is attached, compressed using bzip2 -9 Thanks, Christian. I've CC'd the libstdc++ mailing list, I'll leave it to the next person who replies to decide whether to continue this thread on that list rather than gcc@ I only have to look as far as this to see a major problem: FAIL: 17_intro/headers/c++200x/all.cc (test for excess errors) Excess errors: In file included from /usr/local/src/trunk/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc:111: /usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/memory:86:48: error: tr1_impl/boost_sp_counted_base.h: No such file or directory That should not happen on any platform! And later: FAIL: 17_intro/using_namespace_std_tr1_neg.cc (test for excess errors) Excess errors: In file included from /usr/local/src/trunk/gcc/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc:40: /usr/local/src/trunk/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/memory:86:48: error: tr1_impl/boost_sp_counted_base.h: No such file or directory Again, that should not happen on any platform. Thanks for the logs, I don't have any way to test on that platform unfortunately, but it seems that the symlinks for the new shared_ptr headers are missing. I think that would happen if you hadn't done a clean bootstrap, since the Makefiles generated by configure would not have been updated when I added the new headers. Do you reuse objdir, without removing it entirely? Jon
gcc-4.3-20080125 is now available
Snapshot gcc-4.3-20080125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 131847 You'll find: gcc-4.3-20080125.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080125.tar.bz2 C front end and core compiler gcc-ada-4.3-20080125.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080125.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080125.tar.bz2 C++ front end and runtime gcc-java-4.3-20080125.tar.bz2 Java front end and runtime gcc-objc-4.3-20080125.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080125.tar.bz2The GCC testsuite Diffs from 4.3-20080118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 4.2.3 Status Report (2008-01-21)
On Mon, 21 Jan 2008, Joseph S. Myers wrote: > The 4.2 branch is in regression-only mode. Since it has been more > than two months since the last release, I propose to prepare 4.2.3-rc1 > on Friday 25 January, with either rc2 or the final release on Friday 1 > February. Therefore, the branch will go into slush (all changes must > be approved by an RM) at 18:00 UTC on Friday, until the release is > out. The 4.2 branch is now in this mode. I am preparing 4.2.3-rc1. -- Joseph S. Myers [EMAIL PROTECTED]
Re: small changes of gdbinit.in
On Fri, Jan 25, 2008 at 10:54:18AM -0700, Tom Tromey wrote: > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > Joe> When was $arg0 added to gdb? And why would a gcc developer need > Joe> to use an old gdb? > > $arg0 is ancient, but $argc is pretty new. It was added in GDB 6.4, released June 2006. -- Daniel Jacobowitz CodeSourcery
Re: small changes of gdbinit.in
Joe Buck wrote: On Fri, Jan 25, 2008 at 10:18:01AM -0700, Tom Tromey wrote: "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> On the other hand, old-timers are used to the commands being the way Joe> they are. So I guess that a command that takes a proper argument Joe> should have a different name. You can have it both ways, somewhat: define pt if $argc == 0 set debug_tree ($) else set debug_tree ($arg0) end end Good idea! If anyone wants to patch the commands, that's how it should be done, I think. Personally I'd just change to purely using $arg0 and have people adjust their habits. But then, I've used my own argument-taking pt for years :) But since people can have it both ways, why not? Because it won't work at all with an old gdb? David Daney
Array alignment difference on stack
Hi, With a port of GCC 4.2.1 I'm working on, get_pointer_alignment() (via DECL_ALIGN) returns different values for a char array depending upon whether it is on the stack or not. For example, if the array is a global, get_pointer_alignment() always returns 32, regardless, if there are more than 4 elements in the array. This is good. However, when the array is a local, get_pointer_alignment() returns either 8, 16, or 32, depending upon the size size of the array. i.e. if the array has 11 elements, get_pointer_alignment() will return 8, if it has 16 elements, it will return 32. This has the knock on consequence that inline memcpys aren't efficient as they could be (i.e. I end up with byte-by-byte copies instead of word at a time) for arrays with an odd number of elements. How can I ensure alignment when allocating on the stack? The DATA_ALIGNMENT macro doesn't seem to be having the desired effect in this case. (1I don't even see varasm.c:align_variable being called, so it's not being used). Cheers, Jon
Re: small changes of gdbinit.in
On Wed, Jan 23, 2008 at 08:03:05AM -0500, Daniel Jacobowitz wrote: > On Wed, Jan 23, 2008 at 02:31:11PM +0800, Eric Fisher wrote: > > I guess that the argument of the user defined command in gdbinit.in > > should be $arg0. Also, due to the changes of the structure tree node, > > ptc should be, > > No, the use of $ is deliberate. Print the value you want, then type > ptc by itself. Whether this is the best way or not is up for > discussion, but it's done on purpose :-) This gdb command definition is ancient, and I think it precedes the availability of the $arg0 feature. Before gdb macros had arguments, this is how you had to do it. On the other hand, old-timers are used to the commands being the way they are. So I guess that a command that takes a proper argument should have a different name.
Re: GCC 4.3 target deprecation proposals
Joseph S. Myers wrote: On Thu, 24 Jan 2008, DJ Delorie wrote: At the moment, I'm working on getting sh, h8300, and m32c in shape for 4.3 (or future). I can easily get the test results under 400k by removing some of the multilibs, but I don't think that's a good idea. My sh-elf test tests 38 multilibs, if I only test one that would be a 12k email, which would easily fit past the filters. Are we artificially penalizing targets with many multilibs? If results are being rejected without indicating the target is in terrible shape, you could ask overseers to increase the size limit on gcc-testresults. I'm not actually convinced these long default multilib lists are a good idea; if a user doesn't just want a single multilib for their processor, the long generic list is likely to be wrong for them as well. Depends on the user. For *-rtems*, we build the OS proper multilib and produce libraries. The user links that against a Board Support Package and their application. We are careful to justify each multilib variant in the RTEMS targets since it does lead to longer compile times and longer tool download times when our users install. Here is a count of the multilib variants for the targets we have pre-compiled RTEMS for. Note that all are using gcc 4.2.2 except AVR (4.0.4) and tic4x (3.4.6). arm-rtems4.9 3 avr-rtems4.9 4 bfin-rtems4.9 1 h8300-rtems4.9 7 i386-rtems4.9 6 m68k-rtems4.9 15 mips-rtems4.9 6 powerpc-rtems4.9 15 sh-rtems4.9 11 sparc-rtems4.9 4 tic4x-rtems4.9 4 So you can see that even though we haven't figured out how to run the GCC testsuite when linked against RTEMS, we do have "good news" on a number of targets. With some help from a gcc tester, we should be able to start reporting results on many of the above using simulators. sh has a mechanism for selecting multilibs at configure time, and a more general such mechanism would be good as well (for some targets such as GNU/Linux, it would need to deal with SYSROOT_SUFFIX_SPEC and SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note some targets already generate SYSROOT_SUFFIX_SPEC automatically). Also, while I'm not suggesting I be a maintainer for sh and h8300, if I'm working on them and producing test results, should I send them in anyway? I can always stop sending them when I stop working on them (for whatever reason), but meanwhile, does that count against deprecation? Anyone sending results for a target counts against deprecation. I didn't even look at what version the results are for (although maybe in the 4.4 cycle we should only look at results for 4.3 or later). -- Joseph S. Myers [EMAIL PROTECTED]
Re: Mainline is now regression and documentation fixes only
Jakub Jelinek wrote: On Wed, Jan 23, 2008 at 06:50:02PM +0100, Bernhard Fischer wrote: On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote: As we now reached the goal of less than 100 open serious regressions against GCC 4.3, we are as of now in regression and documentation fixes only mode. This means that for patches going on the trunk the same rules as for release branches apply. While not strictly a regression, is there any chance that we could get this reviewed an applied? http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html I think an exception could be made for this, the risks are small and it should impact just uclibc. But you'd need one of the configury maintainers to ack it. Ok in 48 hours if no one will have objected. Paolo
Re: Finding out what backend instruction pattern matches instruction
Ok, I guess I will try setting the length attribute as you describe and see if it is called at all before hard registers are allocated. Then, I can trace any usage to see if its important. Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Andrew Hutchinson <[EMAIL PROTECTED]> writes: > > > I'm still trying to get my head around length attribute and when/where > > it is used by gcc. The internal manual is vague to say the least. > > > > If I use the method suggested, will it only ever get evaluated after > > reload? Or at least only with hard register assignments made? > > Please reply to the mailing list, not just to me. Thanks. > > I think the length will only ever be evaluated after reload. In any > case, it only really matters after reload. Before reload, you can > return pretty much anything; it won't matter. > > Ian
Re: Mainline is now regression and documentation fixes only
On Wed, Jan 23, 2008 at 06:50:02PM +0100, Bernhard Fischer wrote: > On Wed, Jan 23, 2008 at 12:06:22PM +0100, Richard Guenther wrote: > > > >As we now reached the goal of less than 100 open serious regressions > >against GCC 4.3, we are as of now in regression and documentation fixes > >only mode. This means that for patches going on the trunk the same > >rules as for release branches apply. > > While not strictly a regression, is there any chance that we could get > this reviewed an applied? > > http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00995.html I think an exception could be made for this, the risks are small and it should impact just uclibc. But you'd need one of the configury maintainers to ack it. Jakub
Re: c++0x concepts in gcc call
On Jan 21, 2008 8:08 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to > discuss implementation of the compiler and library parts of the > C++0x concepts proposals. This is to be a brainstorming session, where > we discuss the best way to complete the work, what can be taken from > existing branches, and how to smoothly transition between a > concept-enabled standard library and the current libstdc++. Some notes from the discussion in this call: Organization: - We'll start a fresh branch in the FSF repository dedicated to concepts (it's branches/cxx0x-concepts-branch). Initially, Doug and Jason will be maintainers of this branch - We want to minimize the distance between this branch and mainline: * All non-concepts C++0x features will still go into mainline (unless they depend on concepts) * Type-checking of constrained templates depends on improved type-checking of C++98 templates (particularly, checking of non-dependent expressions), so we'll try to do all of this work in mainline * Doug will merge from mainline to branch regularly - Will salvage what we can from ConceptGCC: concept-checking, archetype generation, and parsing bits will be useful; type-checking of constrained templates needs to be reworked significantly. - We're not going to commit to any schedule, but it'll be a multi-year effort - We're going to delay any decisions about library issues for now. They won't matter until the front end supports enough of concepts to permit their use in the library C++ front end: - Concepts representation: * Concepts, concept maps will be RECORD_TYPEs to reuse as much of that logic as is possible * Archetypes will probably need their own, new tree nodes - Same-type constraints and mapping to archetypes caused a lot of trouble in ConceptGCC: canonical types could simplify this - Constrained templates will create many new nodes in the internal representation that don't need to be around after a constrained template is type-checked; we might need to consider a stricter memory management scheme - Performance of the generated code was a problem with ConceptGCC, which Doug blames on the inliner. We should consider a limited form of inlining in the instantiation of constrained templates to avoid swamping the inliner with the forwarding functions in constrained templates. For more information about the concepts branch, see http://gcc.gnu.org/projects/cxx0x.html#concepts For more information about ConceptGCC, see http://www.generic-programming.org/software/ConceptGCC/ - Doug
Re: small changes of gdbinit.in
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> When was $arg0 added to gdb? And why would a gcc developer need Joe> to use an old gdb? $arg0 is ancient, but $argc is pretty new. Tom
Re: small changes of gdbinit.in
On Fri, Jan 25, 2008 at 10:18:01AM -0700, Tom Tromey wrote: > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > Joe> On the other hand, old-timers are used to the commands being the way > Joe> they are. So I guess that a command that takes a proper argument > Joe> should have a different name. > > You can have it both ways, somewhat: > > define pt > if $argc == 0 > set debug_tree ($) > else > set debug_tree ($arg0) > end > end Good idea! If anyone wants to patch the commands, that's how it should be done, I think. > Personally I'd just change to purely using $arg0 and have people > adjust their habits. But then, I've used my own argument-taking pt > for years :) But since people can have it both ways, why not?
Re: dwarf2 EH address size
> The EH code does seem to use POINTER_SIZE pretty consistently. > DWARF2_ADDR_SIZE is for the debug info, not the exception frame > info. I haven't looked into the history of why this is so. Hmmm... I suppose the EH info is used by the runtime as well, right? So changing to a non-standard addr size complicates the unwinder. I think I'll change binutils then ;-)
uninit-13 testcase: Weird line number in the "uninitialized use" warning
Hello,
the uninit-13.c testcase fails on s390 and s390x:
1 /* { dg-do compile } */
2 /* { dg-options "-O -Wuninitialized" } */
3
4 typedef _Complex float C;
5 C foo()
6 {
7 C f;
8 __imag__ f = 0; /* { dg-warning "is used" "unconditional" } */
9 return f;
10 }
On s390 and s390x the reported line number in the warning is 7 which
is indeed a bit surprising. But anyway also the expected line number
of the warning does not look correct to me. The "uninitialized use"
of the real part of f is done in line 9 so I'm a bit surprised that we
expect the warning to be issued for line 8? I think the dg-warning
directive should be moved one line downwards.
But S/390 reveals another problem here since we do not return complex
numbers in registers. Therefore aggregate_value_p in
gimplify_return_expr returns true and an additional copy statement for
the result is generated:
foo ()
[uninit-13.c : 10] {
float D.1203;
C f;
[uninit-13.c : 8] D.1203 = REALPART_EXPR ;
[uninit-13.c : 8] f = COMPLEX_EXPR ;
[uninit-13.c : 9] = f;
[uninit-13.c : 9] return ;
}
The = f; statement is then lowered by tree-complex to:
foo ()
{
float f$real;
C f;
float D.1203;
:
[uninit-13.c : 8] f$real_2 = f$real_6(D);
[uninit-13.c : 8] f_3 = COMPLEX_EXPR ;
REALPART_EXPR <> = f$real_2;
[uninit-13.c : 9] IMAGPART_EXPR <> = 0.0;
return ;
}
Note that the write to the imaginary part is assigned to a different
source code location. expand_complex_move in tree-complex.c issues the
real part move before the original statement but re-uses the original
statement for the move of the imaginary part.
Replacing __imag__ with __real__ in the testcase causes a warning to
be issued for line 9 instead of 7. So I can hit the two lines
surrounding the expected line :)
Should we do something about this for GCC 4.3 or just XFAIL the
testcases for s390 and s390x?
Bye,
-Andreas-
Re: Seperate the c front-end from GCC
Hi Fabian, Thank you very much, I will have a look at it. Best Regards, Eric Fabian Scheler wrote: > > Hello, > >> I have to use gcc's C parser and the intermediate representation, so that >> I >> can manipulate the basic blocks and CFG. So I need to plug out the parser >> and the intermediate code. I would like to know if it is possible to plug >> out the parser and the intermediate representation code. > > this sound, as if you do not need the rest of gcc ... so just need a > parser and an appropriate intermediate representation. Maybe you > should have a look at LLVM (www.llvm.org) in combination with clang > (clang.llvm.org). > > Ciao, Fabian > > -- View this message in context: http://www.nabble.com/Seperate-the-c-front-end-from-GCC-tp15048379p15091377.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: small changes of gdbinit.in
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: Joe> On the other hand, old-timers are used to the commands being the way Joe> they are. So I guess that a command that takes a proper argument Joe> should have a different name. You can have it both ways, somewhat: define pt if $argc == 0 set debug_tree ($) else set debug_tree ($arg0) end end Personally I'd just change to purely using $arg0 and have people adjust their habits. But then, I've used my own argument-taking pt for years :) Tom
Re: small changes of gdbinit.in
On Fri, Jan 25, 2008 at 10:23:03AM -0800, David Daney wrote: > Joe Buck wrote: > >On Fri, Jan 25, 2008 at 10:18:01AM -0700, Tom Tromey wrote: > >>>"Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > >>Joe> On the other hand, old-timers are used to the commands being the way > >>Joe> they are. So I guess that a command that takes a proper argument > >>Joe> should have a different name. > >> > >>You can have it both ways, somewhat: > >> > >>define pt > >> if $argc == 0 > >>set debug_tree ($) > >> else > >>set debug_tree ($arg0) > >> end > >>end > > > >Good idea! If anyone wants to patch the commands, that's how it should > >be done, I think. > > > >>Personally I'd just change to purely using $arg0 and have people > >>adjust their habits. But then, I've used my own argument-taking pt > >>for years :) > > > >But since people can have it both ways, why not? > > Because it won't work at all with an old gdb? When was $arg0 added to gdb? And why would a gcc developer need to use an old gdb?
4.2.3-rc1 available
GCC 4.2.3 release candidate 1 is now available at: ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.3-RC-20080125/ Please test the tarballs there and report any problems to Bugzilla. CC me on the bugs if you believe they are regressions from previous 4.2 releases that should block the 4.2.3 release. -- Joseph S. Myers [EMAIL PROTECTED]
