Re: GCC 2006 Summer of Code accepted projects
[EMAIL PROTECTED] writes: > I guess everybody is very busy. However, it would be nice to set up a > page in the GCC Wiki with the list of projects accepted for this year > SoC and some links. If someone has this information, I would volunteer > to "wikify" it. I've been assuming that Google was going to put that information up at http://code.google.com/soc/gcc/about.html However, I see that they apparently have not done that yet. Google approved six applications for gcc for Summer of Code 2006. They are: Code parallelization using polyhdral model Plesco Alexandru Escape analysisPaul Biggar Garbage collection tuning Laurynas Biveinis java.lang.management in Classpath Andrew John Hughes Lock free C++ containers Phillip Jordan Wcoercion option Manuel López-Ibáñez Many thanks to all the students who submitted projects. In particular Sanel Zukan, Glauber de Oliveira Costa, Mateusz Rukowicz, and Peng Yuan submitted excellent applications which unfortunately did not make the cut. Thanks also to the people who volunteered to look over all the applications and rate them. Good luck with your projects! Ian
Re: use of changes in STL library
Could you write us what command we should use? We'd like to emphasize that we don't want to recompile whole gcc on our computer, we just want to make use of changes we did in the repository. Short answer is you can't. The gcc build system doesn't support building just the target libraries. You're going to have to build the whole thing. You can build GCC only once, and then modify libstdc++. If you don't want to install GCC, you can install libstdc++ with make install-libstdc++-v3 Paolo
Re: GCC 2006 Summer of Code accepted projects
Google approved six applications for gcc for Summer of Code 2006. They are: Code parallelization using polyhdral model Plesco Alexandru Escape analysisPaul Biggar Garbage collection tuning Laurynas Biveinis java.lang.management in Classpath Andrew John Hughes Lock free C++ containers Phillip Jordan Wcoercion option Manuel López-Ibáñez I can't find my mentor listed in the SOC website anyhwere. Do you have the list of mentors too? Thanks Paul -- Paul Biggar [EMAIL PROTECTED]
Re: use of changes in STL library
Hi thanks a lot for your reply. I'm not sure if you understood what I meant... I'm a student of the Faculty of Mathematics & Computer Science at the Warsaw University of Technology. I'm in my final year of my studies (MSc) and I'm working on my final project. The the subject of my project is: "Enhancing associative containers (map, multimap, set and multiset) in STL with the possibility of choosing the way of their implmentation". So I'm going to develop libstdc++. Now associative containers in STL are implemented by use of red-black trees. What I want to do, is to enable the choice of implementation of these containers by adding one parameter to the templates, so that the containers could by be built by use of b-trees, just vectors or others structures. So my question is: How to make changes in libstdc++ and how to test these changes in the easiest way? Thank you very much for your help. Marek Zuk Paolo Bonzini wrote: Could you write us what command we should use? We'd like to emphasize that we don't want to recompile whole gcc on our computer, we just want to make use of changes we did in the repository. Short answer is you can't. The gcc build system doesn't support building just the target libraries. You're going to have to build the whole thing. You can build GCC only once, and then modify libstdc++. If you don't want to install GCC, you can install libstdc++ with make install-libstdc++-v3 Paolo
Re: use of changes in STL library
On 5/25/06, Marek Zuk <[EMAIL PROTECTED]> wrote: Hi thanks a lot for your reply. I'm not sure if you understood what I meant... I'm a student of the Faculty of Mathematics & Computer Science at the Warsaw University of Technology. I'm in my final year of my studies (MSc) and I'm working on my final project. The the subject of my project is: "Enhancing associative containers (map, multimap, set and multiset) in STL with the possibility of choosing the way of their implmentation". So I'm going to develop libstdc++. Now associative containers in STL are implemented by use of red-black trees. What I want to do, is to enable the choice of implementation of these containers by adding one parameter to the templates, so that the containers could by be built by use of b-trees, just vectors or others structures. So my question is: How to make changes in libstdc++ and how to test these changes in the easiest way? Thank you very much for your help. My personal advice for doing this would be as follows. 1) Learn how to download, compile and install into a custom directory all of gcc. You probably want to look at the options to only compile certain languages (you only want C and C++) 2) Look in the libstdc++-v3 directory. I think everything you want will be in the include directory. The actual headers you include (, , etc.) are in the std directory, for example vector is called std_vector.h. 3) The actual implementations of the algorithms are in bits/. Explore around in here to find the implementations. When you have changed some, recompile by going into the libstdc++-v3 directory. Marek Zuk Paolo Bonzini wrote: > >>> Could you write us what command we should use? >>> We'd like to emphasize that we don't want to recompile whole gcc on our >>> computer, we just want to make use of changes we did in the repository. >> >> Short answer is you can't. The gcc build system doesn't support >> building just the target libraries. You're going to have to build the >> whole thing. > > You can build GCC only once, and then modify libstdc++. If you don't > want to install GCC, you can install libstdc++ with > > make install-libstdc++-v3 > > Paolo >
Re: GCC 2006 Summer of Code accepted projects
"Paul Biggar" <[EMAIL PROTECTED]> writes: > > Google approved six applications for gcc for Summer of Code 2006. > > They are: > > > > Code parallelization using polyhdral model Plesco Alexandru > > Escape analysisPaul Biggar > > Garbage collection tuning Laurynas Biveinis > > java.lang.management in Classpath Andrew John Hughes > > Lock free C++ containers Phillip Jordan > > Wcoercion option Manuel López-Ibáñez > > > I can't find my mentor listed in the SOC website anyhwere. Do you have > the list of mentors too? Sure. Here is the mentor list by student. Plesco AlexandruDaniel Berlin Paul Biggar Daniel Berlin Laurynas Biveinis Daniel Berlin Andrew John Hughes Mark Wielaard Phillip Jordan Benjamin Kosnik Manuel López-Ibáñez Ian Lance Taylor (Daniel is also mentoring four other applications for other organizations. Good thing he's so effective.) Ian
Re: optimizing calling conventions for function returns
On May 23, 2006, at 11:21, Jon Smirl wrote: A new calling convention could push two return addresses for functions that return their status in EAX. On EAX=0 you take the first return, EAX != 0 you take the second. This seems the same as passing an extra function pointer argument and calling that instead of doing a regular return. Tail-call optimization should turn the calll into a jump. Why do you think a custom ABI is necessary? -Geert
[Ada] cross-gnatmake and "gcc"
Hello, does anybody know why a cross-gnatmake needs a "gcc" (host version, no target prefix) in order to cross-build a static library? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Expansion of __builtin_frame_address
Hi, I'd like to gather some opinions and advice on the expansion of __builtin_frame_address, as discussed on gcc-patches last year [1, 2]. This centres on the following comment in expand_builtin_return_addr arising from revision 103294 last year: /* For a zero count, we don't care what frame address we return, so frame pointer elimination is OK, and using the soft frame pointer is OK. For a non-zero count, we require a stable offset from the current frame pointer to the previous one, so we must use the hard frame pointer, and we must disable frame pointer elimination. */ I believe that, when this function is used to expand __builtin_frame_address (), the first sentence isn't true: in some cases, a function does care about the value at count == 0. A concrete example is the glibc backtrace () function [3] which uses the expression __builtin_frame_address (0) to determine the starting point for stack traversal. (It performs subsequent dereferences back down the chain of frame pointers by itself.) The wording of the comment in itself is unfortunately not the end of the issue. Due to the subsequent conditional testing count == 0, the builtin can expand to an erroneous value when the following conditions are met: - the expansion function is invoked with count set to zero; and - the target is such that frame_pointer_rtx and hard_frame_pointer_rtx do not ultimately yield the same address. An example of such an invocation occurs during compilation of the aforementioned backtrace function, and an example of such a target is the ARM. Currently, calling backtrace () on such a target yields a failure. Let us just consider how to fix the ARM case for a moment. The obvious thing to do is to define INITIAL_FRAME_ADDRESS_RTX. However, the correct semantics of such a macro definition would be to: - set current_function_accesses_prior_frames to 1, so that FP is not eliminated in this function; and - return hard_frame_pointer_rtx. I hope I'm not alone in thinking that such a side-effecting macro would be in bad taste. Let us come back to the more general case. As identified above, when expand_builtin_return_addr is used to expand __builtin_frame_address (), we do care about the count == 0 case. I believe that the comment should be adjusted to reflect this whatever other changes, if any, are made. As for the remaining problem, I suggest that we could: (i) always return the hard frame pointer, and disable FP elimination in the current function; or (ii) remove this logic entirely (but preserve the means to communicate any necessity to prevent FP elimination to reload) and insist that all targets define INITIAL_FRAME_ADDRESS_RTX. Any such solution should probably adjust INITIAL_FRAME_ADDRESS_RTX so that it doesn't have to cause a side-effect in order to communicate the information about the frame pointer. Or... (iii) ...the same as option (i), but allow targets to define another macro that will cause the default code to use the soft frame pointer rather than the hard frame pointer, and hence allow FP elimination. (If such a macro were set by a particular target, am I right in thinking that it would be safe to use the soft frame pointer even in the count >= 1 cases?) Option (ii) is in some ways the most satisfactory, as it would provide more certainty (particularly if another target were to be added) that the code is doing the right thing. However it involves a moderate amount of work and I would assume that the current level of enthusiasm in this regard is approximately the same as last year :-) Option (i), which is in all but name the "solution 5" approach [1] proposed last year, means that the "count == 0" case is elevated to the same level of importance as the "count > 0" cases, in line with the use in backtrace (). The problem with this is that on platforms where the soft and hard FPs coincide there is going to be a slight performance degradation, as identified previously, whenever these builtins are used. Someone with more experience will have to enlighten me as to whether this penalty would actually be significant: my intuition tells me that in fact it would not be, though perhaps there are oft-used occurrences of these builtin expansions that I don't know about. (On how many platforms is it the case that the soft and hard FPs actually coincide? If there are platforms where they do _not_ coincide, then presumably those targets can be affected in the same way as I identify above for ARM? I'm confused because the current code seems to assume (in the count == 0 case) that the soft and hard FPs coincide, yet uses the hard rather than the soft FP for count >= 1.) Option (iii) gives the advantage of a working default and removes the pessimization on a target-by-target basis, just when it is known to be safe. If I'm correct in thinking that the setting of the "soft frame pointer" macro would enable the soft frame pointer to be used no matter what the value of count, then this option
Re: GCC 2006 Summer of Code accepted projects
Ian Lance Taylor wrote: > "Paul Biggar" <[EMAIL PROTECTED]> writes: > >>> Google approved six applications for gcc for Summer of Code 2006. >>> They are: >>> >>> Code parallelization using polyhdral model Plesco Alexandru >>> Escape analysisPaul Biggar >>> Garbage collection tuning Laurynas Biveinis >>> java.lang.management in Classpath Andrew John Hughes >>> Lock free C++ containers Phillip Jordan >>> Wcoercion option Manuel López-Ibáñez >> >> I can't find my mentor listed in the SOC website anyhwere. Do you have >> the list of mentors too? I believe we are going to get this stuff posted to the soc website today. > > Sure. Here is the mentor list by student. > > Plesco AlexandruDaniel Berlin > Paul Biggar Daniel Berlin > Laurynas Biveinis Daniel Berlin > Andrew John Hughes Mark Wielaard > Phillip Jordan Benjamin Kosnik > Manuel López-Ibáñez Ian Lance Taylor > > (Daniel is also mentoring four other applications for other > organizations. Good thing he's so effective.) Actually, my name is just as a mentor for a few other orgs as a placeholder. I'm only mentoring a total of 5, and one of them is a Google app, which means i'm just making sure the professor and their student are doing what they should be. Also, Fyodor (nmap) is mentoring 10 this year :)
Re: GCC 2006 Summer of Code accepted projects
Daniel, I think it is not a problem that this info appears also in the GCC wiki, is it? Thus, tonight, I will write it down in the GCC wiki for further reference. If someone wishes to send me further information (links to blogs or webpages), you are welcome to send it to my email address. My intention is to document the progress in my project in the GCC wiki, so if you decide to do something similar, just send me the link (or add it yourself once the page is up). Cheers, Manuel. On 25/05/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: Ian Lance Taylor wrote: > "Paul Biggar" <[EMAIL PROTECTED]> writes: > >>> Google approved six applications for gcc for Summer of Code 2006. >>> They are: >>> >>> Code parallelization using polyhdral model Plesco Alexandru >>> Escape analysisPaul Biggar >>> Garbage collection tuning Laurynas Biveinis >>> java.lang.management in Classpath Andrew John Hughes >>> Lock free C++ containers Phillip Jordan >>> Wcoercion option Manuel López-Ibáñez >> >> I can't find my mentor listed in the SOC website anyhwere. Do you have >> the list of mentors too? I believe we are going to get this stuff posted to the soc website today. > > Sure. Here is the mentor list by student. > > Plesco AlexandruDaniel Berlin > Paul Biggar Daniel Berlin > Laurynas Biveinis Daniel Berlin > Andrew John Hughes Mark Wielaard > Phillip Jordan Benjamin Kosnik > Manuel López-Ibáñez Ian Lance Taylor > > (Daniel is also mentoring four other applications for other > organizations. Good thing he's so effective.) Actually, my name is just as a mentor for a few other orgs as a placeholder. I'm only mentoring a total of 5, and one of them is a Google app, which means i'm just making sure the professor and their student are doing what they should be. Also, Fyodor (nmap) is mentoring 10 this year :)
Re: optimizing calling conventions for function returns
On 5/25/06, Geert Bosch <[EMAIL PROTECTED]> wrote: On May 23, 2006, at 11:21, Jon Smirl wrote: > A new calling convention could push two return addresses for functions > that return their status in EAX. On EAX=0 you take the first return, > EAX != 0 you take the second. This seems the same as passing an extra function pointer argument and calling that instead of doing a regular return. Tail-call optimization should turn the calll into a jump. Why do you think a custom ABI is necessary? The new ABI may not be necessary but adding an extra parameter would require changing source everywhere. The ABI scheme is source transparent and lets the compiler locate the places where it would be a win. The ABI scheme would also let the alternative return be pushed on the stack once no matter how many calls were made, a parameter has to be pushed each time. I ran into another snag that taking the alternative return on a P4 has really bad performance impacts since it messes up prefetch. This sequence is the killer. addl$4, %esp ret /* Return to error return */ I can try coding this as a parameter and see how the compiler generates code differently. The sequence of call, test, jne (or slight variations) occurs in 1000's of places, if a better alternative can be found there could be significant perofrmance gains. I haven't found a good solution yet, any help would be appreciated. -Geert -- Jon Smirl [EMAIL PROTECTED]
Re: [Ada] cross-gnatmake and "gcc"
On Thu, 2006-05-25 at 07:28 -0700, Bernd Trog wrote: > Hello, > does anybody know why a cross-gnatmake needs > a "gcc" (host version, no target prefix) in > order to cross-build a static library? Hard to say without more information, looks like a bug though, I suggest you post detailed commands and logs in gcc.gnu.org/bugzilla :) Laurent
Re: [Ada] cross-gnatmake and "gcc"
--- Laurent GUERBY <[EMAIL PROTECTED]> wrote: > Hard to say without more information, looks like a bug though, I suggest > you post detailed commands and logs in gcc.gnu.org/bugzilla :) OK. It's PR27769. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: optimizing calling conventions for function returns
On 5/25/06, Jon Smirl <[EMAIL PROTECTED]> wrote: I ran into another snag that taking the alternative return on a P4 has really bad performance impacts since it messes up prefetch. This sequence is the killer. addl$4, %esp ret /* Return to error return */ I can try coding this as a parameter and see how the compiler generates code differently. jmp *4($esp) This is slightly faster than addl, ret. But my micro scale benchmarks are extremely influenced by changes in branch prediction. I still wonder how this would perform in large programs. It seems that the sequence ret test jne is very fast compared to jmp *4($esp) Even when they both end up at the same place. It looks to me like the call stack predictor is controlling everything. The only way to make this work would be to figure out some way to get the alternative return address into the call stack predictor. -- Jon Smirl [EMAIL PROTECTED]
Re: optimizing calling conventions for function return
In http://gcc.gnu.org/ml/gcc/2006-05/msg00604.html, you wrote: The sequence of call, test, jne (or slight variations) occurs in 1000's of places, if a better alternative can be found there could be significant perofrmance gains. If the time taken to do the test and branch is really significant compared to the time taken by the called function, the called function probably has the grong interface; the loop should be in the callee. I.e. like using fgetc when you should be using fread. Now, and interesting compiler project would be to do this re-factoring automatically in the compiler... standard inlining will do that, but with a lot of code expansion. It might be more useful to find loops that are similar and place them out-of-line as a new function, and have that inline the original callee. Maybe something for the next Summer Of Code...
Re: optimizing calling conventions for function returns
On May 25, 2006, at 13:21, Jon Smirl wrote: jmp *4($esp) This is slightly faster than addl, ret. The point is that this is only executed in the error case. But my micro scale benchmarks are extremely influenced by changes in branch prediction. I still wonder how this would perform in large programs. The jmp *4($esp) doesn't confuse the branch predictors. Basically the assumption is that call and ret instructions match up. Your addl, ret messes up that assumption, which means the return predictions will all be wrong. Maybe the future link-time optimizations might be able to handle this kind of error-exit code automatically, but for now I think your best bet is handling this explicitly or just not worry about the minor inefficiency. -Geert
Re: GCC 2006 Summer of Code accepted projects
Hi, Projects, students and mentors for SoC 2006 are now listed at http://gcc.gnu.org/wiki/SummerOfCode (you may edit it to link to your blog, website, or wiki page). Cheers, Manuel. On 25/05/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Daniel, I think it is not a problem that this info appears also in the GCC wiki, is it? Thus, tonight, I will write it down in the GCC wiki for further reference. If someone wishes to send me further information (links to blogs or webpages), you are welcome to send it to my email address. My intention is to document the progress in my project in the GCC wiki, so if you decide to do something similar, just send me the link (or add it yourself once the page is up). Cheers, Manuel. On 25/05/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Ian Lance Taylor wrote: > > "Paul Biggar" <[EMAIL PROTECTED]> writes: > > > >>> Google approved six applications for gcc for Summer of Code 2006. > >>> They are: > >>> > >>> Code parallelization using polyhdral model Plesco Alexandru > >>> Escape analysisPaul Biggar > >>> Garbage collection tuning Laurynas Biveinis > >>> java.lang.management in Classpath Andrew John Hughes > >>> Lock free C++ containers Phillip Jordan > >>> Wcoercion option Manuel López-Ibáñez > >> > >> I can't find my mentor listed in the SOC website anyhwere. Do you have > >> the list of mentors too? > > I believe we are going to get this stuff posted to the soc website today. > > > > > Sure. Here is the mentor list by student. > > > > Plesco AlexandruDaniel Berlin > > Paul Biggar Daniel Berlin > > Laurynas Biveinis Daniel Berlin > > Andrew John Hughes Mark Wielaard > > Phillip Jordan Benjamin Kosnik > > Manuel López-Ibáñez Ian Lance Taylor > > > > (Daniel is also mentoring four other applications for other > > organizations. Good thing he's so effective.) > > Actually, my name is just as a mentor for a few other orgs as a placeholder. > I'm only mentoring a total of 5, and one of them is a Google app, which > means i'm just making sure the professor and their student are doing > what they should be. > > Also, Fyodor (nmap) is mentoring 10 this year :) > >
gcc-4.0-20060525 is now available
Snapshot gcc-4.0-20060525 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060525/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 114120 You'll find: gcc-4.0-20060525.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060525.tar.bz2 C front end and core compiler gcc-ada-4.0-20060525.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060525.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060525.tar.bz2 C++ front end and runtime gcc-java-4.0-20060525.tar.bz2 Java front end and runtime gcc-objc-4.0-20060525.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060525.tar.bz2The GCC testsuite Diffs from 4.0-20060518 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: optimizing calling conventions for function return
On Thu, May 25, 2006 at 07:11:59PM +0100, Joern RENNECKE wrote:
> In http://gcc.gnu.org/ml/gcc/2006-05/msg00604.html, you wrote:
>
> >The sequence of call, test, jne (or slight variations) occurs in
> >1000's of places, if a better alternative can be found there could be
> >significant perofrmance gains.
>
> If the time taken to do the test and branch is really significant compared
> to the time taken by the called function, the called function probably has
> the grong interface; the loop should be in the callee.
> I.e. like using fgetc when you should be using fread.
>
> Now, and interesting compiler project would be to do this re-factoring
> automatically in the compiler... standard inlining will do that, but with
> a lot of code expansion. It might be more useful to find loops that are
> similar
> and place them out-of-line as a new function, and have that inline the
> original
> callee. Maybe something for the next Summer Of Code...
Another optimisation that would really help is avoiding function
prologue and epilogue code for functions that make an early exit.
eg. code like
void foo (void *p)
{
if (!p)
return;
/* do lots of stuff here. */
}
Currently we make a stack frame, save all callee saved regs used by "do
lots of stuff", then test p. On the early exit, we restore all those
regs and tear down the stack frame. It would be nice if all this work
could be avoided, particularly since the register restores can cause
load-hit-store cache stalls.
Both of these problems could be solved (at least for static functions)
by some sort of partial function inlining.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
GCC 4.1.1 Released
GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC 4.1.1 contains changes to correct regressions from previous releases, but no new features. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.1.1 subdirectory. If you encounter any difficulties using GCC 4.1.1, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.1 Released
Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC [...] Do you mean "a bug-fix release for problems in GCC 4.1.0"? All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED]
Re: GCC 4.1.1 Released
Mark Mitchell wrote: GCC 4.1.1 has been released. This release is a bug-fix release for problems in GCC 4.0.2. GCC 4.1.1 contains changes to correct regressions from previous releases, but no new features. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.1.1 subdirectory. If you encounter any difficulties using GCC 4.1.1, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Im confused.
Re: Segment registers support for i386
You won't be able to. You're going to need to write your own code that, during the conversion of the tree to RTL, creates RTL expressions which indicate that the memory references use segment registers. This probably won't be easy since there are a lot of contexts where your "far" pointer can be used. I suspect this is where you're going to give up on your project, but if you do then RTL expressions you'll need to create should probably look like: (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var))) After getting GCC to generate expressions like these, then it's a realtively simple case of modifying ix86_decompose_address() to handle the unspec. You might also need to change other backend code for handling addresses. Ross Ridge Thanks for your precisions. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
