Re: ARM not building on head?
On 10.01.15 01:00, Joel Sherrill wrote: FWIW fixing the semicolon only let's the build get to an ICE. :( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64551 Applied the proposal and was able to build a cross-compiler. Andreas On January 9, 2015 4:00:38 PM CST, Jan-Benedict Glaw wrote: On Fri, 2015-01-09 15:05:52 -0600, Joel Sherrill wrote: Hi Does anyone else see this? There is a semi-colon at the end of gcc/config/arm/arm.h:771 which I don't think should be there. g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. -I/users/joel/test-gcc/gcc/gcc/../include -I/users/joel/test-gcc/gcc/gcc/../libcpp/include -I/users/joel/test-gcc/gcc/gcc/../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c In file included from ./tm.h:26:0, from /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void arm_init_libfuncs()’: /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected ‘)’ before ‘;’ token #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: expected primary-expression before ‘)’ token init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ make[2]: *** [arm.o] Error 1 make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' make: *** [all] Error 2 Sure, my build robot found it as well; it's probably just a typo. Easy to fix. MfG, JBG --joel
Re: ARM not building on head?
On January 9, 2015 4:00:38 PM CST, Jan-Benedict Glaw wrote: >On Fri, 2015-01-09 15:05:52 -0600, Joel Sherrill > wrote: >> Hi >> >> Does anyone else see this? There is a semi-colon at the end of >> gcc/config/arm/arm.h:771 which I don't think should be there. >> >> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE >-fno-exceptions >> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing >> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros >> -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. >> -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. >> -I/users/joel/test-gcc/gcc/gcc/../include >> -I/users/joel/test-gcc/gcc/gcc/../libcpp/include >> -I/users/joel/test-gcc/gcc/gcc/../libdecnumber >> -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber >> -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o >-MMD >> -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c >> In file included from ./tm.h:26:0, >> from >/users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void >> arm_init_libfuncs()’: >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected >> ‘)’ before ‘;’ token >> #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); >>^ >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in >> expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ >> init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); >> ^ >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: >expected >> primary-expression before ‘)’ token >> init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); >> ^ >> make[2]: *** [arm.o] Error 1 >> make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' >> make[1]: *** [all-gcc] Error 2 >> make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' >> make: *** [all] Error 2 > >Sure, my build robot found it as well; it's probably just a typo. Easy >to fix. It was easy to and lets the build get to an ICE. I will retest Monday and hope someone fixes it. I am sure someone will want it fixed. :) >MfG, JBG --joel
Re: ARM not building on head?
On Fri, 2015-01-09 15:05:52 -0600, Joel Sherrill wrote: > Hi > > Does anyone else see this? There is a semi-colon at the end of > gcc/config/arm/arm.h:771 which I don't think should be there. > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. > -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. > -I/users/joel/test-gcc/gcc/gcc/../include > -I/users/joel/test-gcc/gcc/gcc/../libcpp/include > -I/users/joel/test-gcc/gcc/gcc/../libdecnumber > -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o -MMD > -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c > In file included from ./tm.h:26:0, > from /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: > /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void > arm_init_libfuncs()’: > /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected > ‘)’ before ‘;’ token > #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); >^ > /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in > expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ > init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); > ^ > /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: expected > primary-expression before ‘)’ token > init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); > ^ > make[2]: *** [arm.o] Error 1 > make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' > make[1]: *** [all-gcc] Error 2 > make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' > make: *** [all] Error 2 Sure, my build robot found it as well; it's probably just a typo. Easy to fix. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, träume ich. the second : signature.asc Description: Digital signature
Re: ARM not building on head?
Appologies, this is mine. But I couldn't bootstrap arm so far. On 09.01.15 22:05, Joel Sherrill wrote: Does anyone else see this? There is a semi-colon at the end of gcc/config/arm/arm.h:771 which I don't think should be there. g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. -I/users/joel/test-gcc/gcc/gcc/../include -I/users/joel/test-gcc/gcc/gcc/../libcpp/include -I/users/joel/test-gcc/gcc/gcc/../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c In file included from ./tm.h:26:0, from /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void arm_init_libfuncs()’: /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected ‘)’ before ‘;’ token #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); Committed as obvious. Again, sorry for the troubles. Andreas 2015-01-09 Andreas Tobler * config/arm/arm.h (MAX_SYNC_LIBFUNC_SIZE): Delete semicolon. Index: arm.h === --- arm.h (revision 219411) +++ arm.h (working copy) @@ -768,7 +768,7 @@ /* The maximum size of the sync library functions supported. */ #ifndef MAX_SYNC_LIBFUNC_SIZE -#define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); +#define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD) #endif
ARM not building on head?
Hi Does anyone else see this? There is a semi-colon at the end of gcc/config/arm/arm.h:771 which I don't think should be there. g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. -I/users/joel/test-gcc/gcc/gcc/../include -I/users/joel/test-gcc/gcc/gcc/../libcpp/include -I/users/joel/test-gcc/gcc/gcc/../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c In file included from ./tm.h:26:0, from /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void arm_init_libfuncs()’: /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected ‘)’ before ‘;’ token #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: expected primary-expression before ‘)’ token init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ make[2]: *** [arm.o] Error 1 make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' make: *** [all] Error 2 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: GCC 5 Status Report (2015-01-08), Stage 4 to start soon
On 01/09/15 08:32, Joel Sherrill wrote: Piling on here. For RTEMS, we have 5 targets with GCC PRs reported. Ignoring the avr and m32c, we have arm, m68k and nios2 all with regressions since 4.9. I think these PRs are important enough that they should get consideration: + arm: ICE GCC PR64460 segfault for -O2 and xscale + m68k: GCC PR64461 invalid code for all Coldfires I can't really test coldfire, but Andreas's comment indicates we can just disable that pattern. Feel free to assign it to me. Not sure if it's strictly a regression, but I'd argue that it's broken enough to warrant fixing regardless of what stage we're in. If indeed it's as simple as disabling that pattern, the chances for collateral damage are trivially small. jeff
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley wrote: > On 01/09/2015 12:30 PM, Richard Biener wrote: >> Does --disable-lto-plugin work? > > Over to you, Cyd. > > Andrew. > Yes, it allows the build to continue successfully. Specifically it allows the libgcc_s.so to be built. Brief background: the fakechroot lib is specific to the environment I'm using on Android to build GCC; it simulates a Linux-style filesystem making it easier to port various utilities and programs.
Re: GCC 5 Status Report (2015-01-08), Stage 4 to start soon
Piling on here. For RTEMS, we have 5 targets with GCC PRs reported. Ignoring the avr and m32c, we have arm, m68k and nios2 all with regressions since 4.9. I think these PRs are important enough that they should get consideration: + arm: ICE GCC PR64460 segfault for -O2 and xscale + m68k: GCC PR64461 invalid code for all Coldfires + nios2: GCC PR64377 GCC doesn't build. Target independent change broke this target's option processing. The m68k and the nios2 PRs have been git bisected, are narrowed down to the source, and have meaningful comments. I have not been able to get a really useful git bisect on the arm yet (results I have are posted) but no one has even commented. For completeness, the avr and m32c PRs are: + avr: ICE GCC PR63752 + m32c: ICE GCC PR64546 Thanks. --joel On 1/9/2015 5:12 AM, Christian Bruel wrote: > Hi Ramana, > > any chance to get the attribute target support for ARM review in time > for stage 4 ? > > Many thanks > > Christian > > On 01/08/2015 11:32 AM, Jakub Jelinek wrote: >> The trunk is still in Stage 3 now, which means it is open for general >> bugfixing, but will enter Stage 4 on Friday, 16th, end of day (timezone >> of your preference). Once that happens, only wrong-code fixes, regression >> bugfixes and documentation fixes will be allowed, as is normal for >> our release branches too. >> >> There are still a few patches that have been posted during Stage 1, >> please get them committed into trunk before Stage 4 starts. >> >> Still misleading quality data below - some P3 bugs have not been >> re-prioritized. >> >> Quality Data >> >> >> Priority # Change from last report >> --- --- >> P1 39+ 24 >> P2 98+ 15 >> P3 48- 84 >> --- --- >> Total 185- 45 >> >> >> Previous Report >> === >> >> https://gcc.gnu.org/ml/gcc/2014-11/msg00249.html >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Three symbols in libgcc with no leading __
I noticed that there are three symbols in libgcc with no leading __: isinfd32, isinfd64, isinfd128. Is there any reason for that? As far as I can see GCC will never generate calls to those functions (especially because PR 43374 means that the isinf macro doesn't currently work for decimal floating point numbers). It seems to me that libgcc shouldn't be in the business of providing general purpose decimal floating point functions (and just providing those three isn't too useful anyhow). Should these be changed to have leading underscores? Should they simply be removed? Ian
Re: Android native build of GCC
On 01/09/2015 12:30 PM, Richard Biener wrote: > Does --disable-lto-plugin work? Over to you, Cyd. Andrew.
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 1:16 PM, Andrew Haley wrote: > On 01/09/2015 10:33 AM, Richard Biener wrote: >> On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote: >>> Android native GCC can't support LTO because of a lack of support for >>> dlopen() in the C library. How should we patch the configury to disable >>> LTO by default? >> > >> How does LTO need dlopen? It seems it only cannot use the linker >> plugin > > That's right, it's the plugin which is causing the problem. Building it, I suppose? Does --disable-lto-plugin work? Richard. >> in which case the existing check for plugin-supporting ld should >> catch it? > > It doesn't seem to. The problem is probably caused by > libfakechroot.so, which intercepts calls to dlopen() and tries to > forward them. Unfortunately dlopen() is not in Android's libc, so > libfakechroot returns a link error for dlopen(). I don't know what > the check for plugin-supporting ld does, but I guess it doesn't call > dlopen(). > > I'll grant you that this isn't really our bug: libfakechroot shouldn't > be exporting dlopen() on Android. > > Andrew.
Re: Android native build of GCC
On 01/09/2015 10:33 AM, Richard Biener wrote: > On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote: >> Android native GCC can't support LTO because of a lack of support for >> dlopen() in the C library. How should we patch the configury to disable >> LTO by default? > > How does LTO need dlopen? It seems it only cannot use the linker > plugin That's right, it's the plugin which is causing the problem. > in which case the existing check for plugin-supporting ld should > catch it? It doesn't seem to. The problem is probably caused by libfakechroot.so, which intercepts calls to dlopen() and tries to forward them. Unfortunately dlopen() is not in Android's libc, so libfakechroot returns a link error for dlopen(). I don't know what the check for plugin-supporting ld does, but I guess it doesn't call dlopen(). I'll grant you that this isn't really our bug: libfakechroot shouldn't be exporting dlopen() on Android. Andrew.
Re: GCC 5 Status Report (2015-01-08), Stage 4 to start soon
Hi Ramana, any chance to get the attribute target support for ARM review in time for stage 4 ? Many thanks Christian On 01/08/2015 11:32 AM, Jakub Jelinek wrote: The trunk is still in Stage 3 now, which means it is open for general bugfixing, but will enter Stage 4 on Friday, 16th, end of day (timezone of your preference). Once that happens, only wrong-code fixes, regression bugfixes and documentation fixes will be allowed, as is normal for our release branches too. There are still a few patches that have been posted during Stage 1, please get them committed into trunk before Stage 4 starts. Still misleading quality data below - some P3 bugs have not been re-prioritized. Quality Data Priority # Change from last report --- --- P1 39+ 24 P2 98+ 15 P3 48- 84 --- --- Total 185- 45 Previous Report === https://gcc.gnu.org/ml/gcc/2014-11/msg00249.html
Re: Android native build of GCC
On Thu, Jan 8, 2015 at 11:12 AM, Andrew Haley wrote: > Android native GCC can't support LTO because of a lack of support for > dlopen() in the C library. How should we patch the configury to disable > LTO by default? How does LTO need dlopen? It seems it only cannot use the linker plugin in which case the existing check for plugin-supporting ld should catch it? Richard. > Thanks, > Andrew.
Re: Vectorization opportunities for conditional branches.
On Mon, Jan 5, 2015 at 3:27 AM, Ajit Kumar Agarwal
wrote:
>
> The following fig (1) shows an implementation of the SSQ kernel from the BLAS
> Library in ATLAS.
> Fig(2) shows the conversions of the IF-THEN-ELSE in Fig(1) to vectorized
> code. Normally in the automatic vectorization the IF-THEN-ELSE is
> vectorized only after the IF-CONVERSION that converts control flow to Data
> flow and then raise the opportunity of vectorization.
>
> The Fig(1) and Fig(2) is taken from the article
>
> " Vectorization Past Dependent Branches through speculation" Qing Yi etal.
>
> The following conversion given in the above article checks the IF-THEN and
> IF-ELSE separately and checks for the candidates of vectorization.
> If the IF-THEN can be vectorized and IF-ELSE cannot be vectorized and the
> whole conversion given in the Fig (2) shows how the conditional branches
> can be vectorized.
>
> In the below case the IF-THEN-ELSE need not be IF-CONVERTED and the
> conditional branches is vectorized by the transformation shown in FIG (2).
>
> ssq = *ssq0;
> scal = *scal0;
>
> For(i=0;I < N ;i++)
> {
> ax= x[i];
> ax = ABS & Ax;
> If( ax <=scal)
> {
> t0= ax/scal;
> ssq+= t0 * t0;
> }
>Else
>{
>t0= scal/ax;
>t0 = t0 * t0;
> t1= ssq * t0;
> ssq = 1.0 + t1;
>scal = ax;
>}
> }
> *ssq0 = ssq;
> *scal0 = scal;
>
> FIG ( 1)
>
> Transformed to
>
> VECTOR_PROLOGUE:
> VABS = {ABS, ABS, ABS, ABS};
> Vssq = {ssq0, 0.0, 0.0, 0.0};
> Vscal = { scal, scal, scal , scal};
>
> VECTOR_LOOP:
> For(i=0;I < N4 ;i++)
> {
> Vax= x[i: I+3];
> Vax = VABS & Vax;
> If( VEC_ANY(Vax > Vscal)
> GOTO SCALAR_RESTART;
>
> Vt0= vax/vscal;
>Vssq+= Vt0 *V t0;
>continue;
>
>SCALAR_RESTART:
> // Vector to Scalar.
>
>Ssq= sum(vssq[0:3]);
>
> // Scalar Loop
> For(j=0;I < 4 ;j++)
> {
> ax= x[i+j];
> ax = AbS & Ax;
> If( ax >scal)
> {
> t0= scal/ax;
>t0 = t0 * t0;
> t1= ssq * t0;
> ssq = 1.0 + t1;
>scal = ax;
> }
> Else{
> t0= ax/scal;
> ssq+= t0 * t0;
> }
> }
> Vssq= { ssq, 0.0, 0.0, 0.0};
> Vscal = { scal, scal, scal, scal}
>
> }
> VECTOR_EPILOGUE:
>
> ssq = sum(Vssq[0:3]);
> scal = Vscal[0];
>
> FIG(2).
>
> This looks interesting to me considering the IF-THEN-ELSE inside the Loop to
> be vectorized as given above without IF-Converting.
> I am not sure how many such sequences of the code will be triggered for SPEC
> benchmark but it looks interesting to me to be
> implemented.
>
> Thoughts Please ?
Surely interesting, but I'd say that without profile data it might be hardly
profitable in practice.
Richard.
> Thanks & Regards
> Ajit
