Hi Ramana,
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: Wednesday, January 14, 2015 7:21 PM
> On Wed, Jan 14, 2015 at 10:20 AM, Thomas Preud'homme
> wrote:
> > When compiling for size, live high registers are not saved in function
> prolog in ARM backend in Thumb mode.
2015-01-22 17:38 GMT+01:00 Paul Richard Thomas :
> As it happens I loaded this patch up last night to see if I could plug
> the last leak in my patch for PR63205, which is making heavy use of
> the default finalizers. It seemed to do the job. As you said in the PR
> it appears to be a typo and real
On Thu, 22 Jan 2015, Richard Henderson wrote:
> On 01/21/2015 11:52 PM, Richard Biener wrote:
> > On January 21, 2015 10:23:56 PM CET, Richard Henderson
> > wrote:
> >> On 12/29/2014 06:04 AM, Thomas Preud'homme wrote:
> >>> Since 16bit byteswap can be done via an 8 bit rotation (and it is the
>
On Thu, 22 Jan 2015, Jan Hubicka wrote:
> >
> > As said in the other thread - this makes sure we don't perform inlining
> > that might end up generating invalid code. It also preserves
> > user-provided optimize attributes more properly.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-g
On Fri, 23 Jan 2015, Prathamesh Kulkarni wrote:
> On 21 January 2015 at 23:18, Eric Botcazou wrote:
> >> Thanks. I had wrongly made eliminate_constant_term() static, reverted
> >> that change and it builds on
> >> all targets in config-list.mk.
> >> Committed as r219655 (hopefully nothing breaks!
Hi Richard,
When detecting a 16-bit hand-crafted byte swap, the bswap pass replaces the
sequence of statements by a rotation left of 8 bits of the same type as the
source. For source whose type size is bigger than 16 bits this is wrong. For
instance,
int swap(int x)
{
return (unsigned short) (
On Thu, Jan 22, 2015 at 9:39 PM, Jakub Jelinek wrote:
> Hi!
>
> The latest testcase from the PR ICEs on running out of stack during GC
> collection, because we have a long chain of dw_loc_descr_nodes.
> Am not adding the testcase to the testsuite because it looks too costly.
>
> Bootstrapped/regte
On Fri, 23 Jan 2015, Thomas Preud'homme wrote:
> Hi Richard,
>
> When detecting a 16-bit hand-crafted byte swap, the bswap pass replaces the
> sequence of statements by a rotation left of 8 bits of the same type as the
> source. For source whose type size is bigger than 16 bits this is wrong. F
Hi all,
comitted as r220032.
Regards,
Andre
On Tue, 13 Jan 2015 14:04:50 +0100
Andre Vehreschild wrote:
> Hi,
>
> is this patch commited now? I don't have the rights to do so myself.
>
> - Andre
>
> On Sun, 28 Dec 2014 17:17:50 +0100
> FX wrote:
>
> >
> > > 2014-12-28 Andre Vehr
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Friday, January 23, 2015 6:01 PM
> > + if (bswap && n->range == 16)
> > +bswap_type = TYPE_UNSIGNED (TREE_TYPE (src)) ?
> short_unsigned_type_node
> > +:
> short_integer_type_node;
>
> I don'
On 22/01/15 21:31, Christophe Lyon wrote:
On 22 January 2015 at 16:22, Tejas Belagod wrote:
On 22/01/15 14:28, Christophe Lyon wrote:
On 22 January 2015 at 12:19, Tejas Belagod wrote:
On 21/01/15 15:07, Christophe Lyon wrote:
On 19 January 2015 at 17:54, Marcus Shawcroft
wrote:
On 1
On Fri, 23 Jan 2015, Thomas Preud'homme wrote:
> > From: Richard Biener [mailto:rguent...@suse.de]
> > Sent: Friday, January 23, 2015 6:01 PM
> > > + if (bswap && n->range == 16)
> > > +bswap_type = TYPE_UNSIGNED (TREE_TYPE (src)) ?
> > short_unsigned_type_node
> > > +
On Thu, Jan 15, 2015 at 12:10 PM, Tony Liu wrote:
> Hi,
>
> This is the patch to improve the test case gcc.target/arm/scd42-1.c for both
> UAL and non-UAL. It now checks UAL format assembly code for Thumb1 and
> Thumb2 while non-UAL format assembly code for ARM mode.
OK.
Ramana
>
> With this pa
"make TAGS" in the GDB source tree fails because libdecnumber doesn't
have a TAGS target. This patch fixes that:
commit 53bef1c10759f1fd7faf675459871b2f4cc12e53
Author: Eli Zaretskii
Date: Thu Jan 22 21:07:31 2015 +0200
Another part of fixing "make TAGS".
libdecnumber/
2015-0
The following should fix gcc.dg/vect/vect-33.c failing on arm
by properly guarding the scan-tree-dumps for vect64 tagets that
also can vectorize with v16qi. I've choosen to use
vect_multiple_sizes for that, hoping we don't have targets
that do vect32.
Reliably writing vectorizer testcases gets h
Hi,
This is an almost obvious patch to fix PR64231 as discovered by A.
Pinksi and as proposed by Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
Regressions happy. OK to commit?
Thanks,
Tejas.
ChangeLog:
gcc/
2015-01-23 Tejas Belagod
Andrew Pinski
J
On 23 January 2015 at 11:18, Tejas Belagod wrote:
> On 22/01/15 21:31, Christophe Lyon wrote:
>>
>> On 22 January 2015 at 16:22, Tejas Belagod wrote:
>>>
>>> On 22/01/15 14:28, Christophe Lyon wrote:
On 22 January 2015 at 12:19, Tejas Belagod
wrote:
>
>
> On 21/01
Ping, with a caveat.
This bug appears on all release branches and is thus not a regression.
Should it be slotted for next stage 1?
Kyrill
On 16/01/15 16:55, Kyrill Tkachov wrote:
Hi all,
This PR is about GCC emiting 'bx lr' instructions when compiling with
-march=armv2 or armv3(!). It should
On Tue, Jan 20, 2015 at 10:58 AM, Jakub Jelinek wrote:
>> >>> The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only
>> >>> the amd64 crtbegin.o is affected, the i386 one is fine.
>> >>
>> >> Please split sysv4-common.h out of i386/sysv4.h, similar to how
>> >> i386/gnu-user.h and
Hi Jakub,
I committed the patch with the change log corrections you said.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034
regards,
Venkat.
On 23 January 2015 at 02:14, Jakub Jelinek wrote:
> On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote:
>> On Thu, Jan 22, 2015 at
On Fri, Jan 23, 2015 at 12:56:02PM +0100, Uros Bizjak wrote:
> I'm testing the attached patch that moves the definition to libgcc
> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
> implement the fix for the Solaris/x86, presumably in the same way?
>
> libgcc/ChangeLog:
>
> 20
On Fri, Jan 23, 2015 at 1:04 PM, Jakub Jelinek wrote:
> On Fri, Jan 23, 2015 at 12:56:02PM +0100, Uros Bizjak wrote:
>> I'm testing the attached patch that moves the definition to libgcc
>> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
>> implement the fix for the Solaris/x86
Applied to trunk.
Richard.
2015-01-23 Richard Biener
PR testsuite/63439
* gcc.dg/vect/bb-slp-11.c: Require vect_pack_trunc.
* gcc.dg/vect/bb-slp-26.c: Require vect_hw_misalign.
Index: gcc/testsuite/gcc.dg/vect/bb-slp-11.c
=
On 23 January 2015 at 12:42, Christophe Lyon wrote:
> On 23 January 2015 at 11:18, Tejas Belagod wrote:
>> On 22/01/15 21:31, Christophe Lyon wrote:
>>>
>>> On 22 January 2015 at 16:22, Tejas Belagod wrote:
On 22/01/15 14:28, Christophe Lyon wrote:
>
>
> On 22 January 2015
*Ping*
Cheers,
James
On Mon, Jan 19, 2015 at 05:44:27PM +, James Greenhalgh wrote:
>
> On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote:
> >
> >
> > On 16/01/15 10:20, Marcus Shawcroft wrote:
> > > On 15 January 2015 at 09:50, James Greenhalgh
> > > wrote:
> > >
> > >>
The constexpr expansion code doesn't understand the C++ front end
statement tree codes; for expanding a constexpr call it expects the
gimplified form. For now let's not bother trying to expand a
statement-expression.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e01d0162df7b21bb26449e
The problem here was that darwin uses CONST_DECL for an aggregate
constant, while the C++ front end expects it to only be used for
enumerators. Adjusting that in this one place fixes the testcase.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e7e659890bfa248aa57eefd62992a71d8d0bd399
Au
Hi,
This patch fixes PR64707.
It marks fopenmp as LTO option, which enables openmp builtins in lto1.
Bootstrapped, reg-tested on x86_64 and committed.
Thanks,
- Tom
2015-01-22 Tom de Vries
PR libgomp/64707
* lto-opts.c (lto_write_options): Output non-explicit conservative
-fno-openmp.
Hi,
This patch fixes PR64672.
It marks fopenacc as LTO option, which enables openacc builtins in lto1.
Bootstrapped, reg-tested on x86_64 and committed.
Thanks,
- Tom
2015-01-22 Tom de Vries
PR libgomp/64672
* lto-opts.c (lto_write_options): Output non-explicit conservative
-fno-openacc
On 21/01/15 17:19 +, Jonathan Wakely wrote:
On 21/01/15 18:09 +0100, Rainer Orth wrote:
Indeed: before and after this change, Solaris bootstrap is broken. Now
I get
ld: fatal: libstdc++-symbols.ver-sun: 6153: symbol 'std::codecvt::do_unshift(__mbstate_t&, char*, char*, char*&) const': symb
Hello.
Following patch is a fix for PR ipa/64693, where ICF merges a pair of functions
that somehow take a references to a different functions. Unfortunately, such
function
pointer can be used for function comparison that can break an executable.
Tested on x86_64-linux-pc and no regression is a
With my patch for 57510 we are now using build_vec_init for
sub-CONSTRUCTORs of array type, but we weren't removing the non-constant
initialization from the CONSTRUCTOR.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 59b7dc8ddf4fdd1505a436dbc4de0499fff9aa41
Author: Jason Merrill
Date:
[CC ing build, libquadmath, libcilkrts maintainers]
On 01/23/2015 02:53 AM, Ian Lance Taylor wrote:
> On Thu, Jan 22, 2015 at 3:44 PM, Matthias Klose wrote:
>>
>> However for the libbacktrace and the libsanitizer builds, the
>> AM_ENABLE_MULTILIB
>> macro is included way too late. Scan the gene
On Mon, Jan 19, 2015 at 09:41:11AM -0500, David Malcolm wrote:
> OK for trunk?
>
> gcc/ChangeLog
>
> * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
> Support the JIT by using 0 as the language type.
Ok, thanks.
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs600
Hi,
A bug was exposed by LRA for loongson-shift-count-truncated-1.c and
loongson-simd.c with -O0 optimization. These testcases were ICEing
with 'Max. number of generated reloads insns per insn is achieved (90)'
error.
The problem appears to be with vector modes where contents of memory
is meant
On 01/23/2015 09:43 AM, Jason Merrill wrote:
The constexpr expansion code doesn't understand the C++ front end
statement tree codes; for expanding a constexpr call it expects the
gimplified form. For now let's not bother trying to expand a
statement-expression.
This is what I'm actually checki
Hi All,
In a process of testing omp-simd tests we found out that couple
important benchmark did not show any speed-up with aggressive
if-conversion since the hottest loops have not been vectorized.
Here is a simple patch that resolves vectorization issue related to
aggressive if-conversion:
(1) Us
On Jan 23, 2015, at 3:03 AM, Tejas Belagod wrote:
> This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi and
> as proposed by Jakub.
Kinda crappy code. The macro to use here should take the number of bits as an
int, and wether the constant is signed or not.
FITS (x, 32,
On Jan 22, 2015, at 6:07 PM, Sandra Loosemore wrote:
> The ARM run-time ABI says that long long division by zero should return the
> result
> This isn't a regression (AFAICT, this has never worked properly), so I don't
> know if it's appropriate to consider this for trunk at this time.
So, the
On Fri, Jan 23, 2015 at 08:48:43AM -0800, Mike Stump wrote:
> On Jan 23, 2015, at 3:03 AM, Tejas Belagod wrote:
> > This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi
> > and as proposed by Jakub.
>
> Kinda crappy code. The macro to use here should take the number of bits
On 17 Jan 02:16, Ilya Verbin wrote:
> Hi!
>
> Unfortunately, it broke offloading from shared libraries (I mean common libs
> with NEEDED entries, not dlopened). Such things are not covered by the
> testsuite, that's why you missed this issue. Here is a simple testcase:
> ...
> So, you don't ass
Hi,
The POWER8 processor greatly improves performance of unaligned vector
loads and stores. Except for certain corner cases the compiler can't
readily track, an unaligned vector load or store performs equivalently
to an aligned one.
To exploit this in the auto-vectorizer requires two changes. T
On Fri, Jan 23, 2015 at 08:20:53PM +0300, Ilya Verbin wrote:
> On 17 Jan 02:16, Ilya Verbin wrote:
> > Hi!
> >
> > Unfortunately, it broke offloading from shared libraries (I mean common libs
> > with NEEDED entries, not dlopened). Such things are not covered by the
> > testsuite, that's why you
Hi!
The -freport-bug changes added an undesirable empty line at the end of
gcc -v .
That extra line is desirable just in the -freport-bug dumps, so moved there.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-23 Jakub Jelinek
PR driver/64737
* gcc
Hi!
On the following testcase we ICE, because scan_sharing_clauses doesn't
install_var_field. Generally in target {data,update} we don't want
to pointer translate when nothing will really use it, but for
OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION we actually do want data transfer
to happen and we hav
On 01/23/2015 10:22 AM, Jakub Jelinek wrote:
> 2015-01-23 Jakub Jelinek
>
> PR driver/64737
> * gcc.c (print_configuration): Don't print a blank line at the end
> here...
> (run_attempt): ... but here unstead.
Ok.
r~
Phew... ok, I'm a little stuck here with the interaction between
dwarf2out and LTO, and I'm hoping y'all can shed some light. Please
bear with me through the verbosity, it gets clearer (I hope) near the end.
On 01/16/2015 12:45 PM, Jason Merrill wrote:
On 01/16/2015 12:50 PM, Aldy Hernandez w
On 01/23/2015 10:06 AM, Mike Stump wrote:
On Jan 22, 2015, at 6:07 PM, Sandra Loosemore
wrote:
The ARM run-time ABI says that long long division by zero should
return the result
This isn't a regression (AFAICT, this has never worked properly),
so I don't know if it's appropriate to consider
On Fri, Jan 23, 2015 at 1:08 PM, Uros Bizjak wrote:
>>> I'm testing the attached patch that moves the definition to libgcc
>>> *and* wraps it in __i386__ to fix multilibs. Rainer, can you please
>>> implement the fix for the Solaris/x86, presumably in the same way?
>>>
>>> libgcc/ChangeLog:
>>>
>
This patch to libgo avoids crashing if there is no debug info when
calling runtime.Callers. This is particularly useful because memory
profiling, which is on at a low rate by default, will call
runtime.Callers even though the program itself does not call it. This
addresses part of GCC PR 64595.
Hello!
movd is a SSE2 insn.
2015-01-23 Uros Bizjak
* config/i386/sse.md (sse2_loadld): Set attribute isa to sse2 for
alternative 1.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN as obvious.
Index: config/i386/sse.md
==
> 2015-01-23 Robert Suchanek
>
> * config/mips/mips.c (mips_hard_regno_mode_ok_p): Prohibit
> accumulators
> for all vector modes.
This seems like a genuine bug and although it can only be triggered by
loongson or paired-single support it probably qualifies for fixing.
My suspicion
st-hello-world.exe.log.txt
+++ b/gcc/jit/docs/internals/test-hello-world.exe.log.txt
@@ -1,3 +1,5 @@
+JIT: libgccjit (GCC) version 5.0.0 20150123 (experimental)
(x86_64-unknown-linux-gnu)
+JIT: compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
The patch was successfully bootstrapped on x86-64 and ppc64 and
tested on x86-64.
Committed as rev.220060.
2015-01-23 Vladimir Makarov
PR target/64317
* lra-lives.c (make_hard_regno_born):
On 01/15/2015 12:13 AM, Jakub Jelinek wrote:
> On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
That last line means the compiler is free to delete a non-volatile
asm with a memory clobber if that asm is not needed for dataflow. Or
that is how I read it; it is trying
Hi Venkat,
> I committed the patch with the change log corrections you said.
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034
unfortunately, it broke bootstrap for an i686-unknown-linux-gnu
--enable-targets=all build: the 64-bit libtsan.so fails to link:
.libs/tsan_interface_ato
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Friday, January 23, 2015 2:51 PM
> To: Robert Suchanek; gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine
> Subject: RE: [PATCH RFA MIPS] Prohibit vector modes in accumulators
>
> > 2015-01-23 Robert S
On Wed, Jan 21, 2015 at 9:10 PM, Tim Shen wrote:
> Submitted version.
I think this patch fits 4.9 branch well?
--
Regards,
Tim Shen
> Hello.
>
> Following patch is a fix for PR ipa/64693, where ICF merges a pair of
> functions
> that somehow take a references to a different functions. Unfortunately, such
> function
> pointer can be used for function comparison that can break an executable.
>
> Tested on x86_64-linux-pc and
On Fri, Jan 23, 2015 at 12:52:37PM -0800, Richard Henderson wrote:
> > ./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm (""
> > ::: "memory")
>
> I think that it's uses like these -- which may well have been written
> by folks that also work on gcc -- that are proof that we
On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote:
> I understand that argument. But it is not what GCC actually does, nor
> what I think it should do. Consider this program:
>
> --- 8< ---
> int main(void)
> {
> int x[100], y[100];
>
> x[31] = 42;
>
> asm("#
Go programs assume that they can always find the location that called
them, via standard library functions like
http://golang.org/pkg/runtime/#Caller . In gccgo this is implemented
via libbacktrace, which uses debug info. This means that many Go
programs only works correctly if compiled with -g.
The following patch builds and installs the JIT documentation for
the website (just HTML for now).
It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess),
but I was able to use this to generate sane-looking documentation,
both for the .texi files, and for the JIT documentation.
Test
Hi,
r218005 added:
+ /* ??? Store somewhere better. */
+ unsigned short ruid;
+ if (restrict_var->ruid == 0)
+ restrict_var->ruid = ++last_ruid;
+ MR_DEPENDENCE_CLIQUE (ref) = clique;
+ MR_DEPENDENCE_BASE (ref) = restrict_var->ruid;
Since ruid isn't initia
Hi Catherine,
> The patch looks reasonable, but I'd like to see a test case that fails before
> we agree to include for GCC 5.0.
It's possible to reproduce ICEs with SVN revision 212354 on mipsel-linux-gnu
target. The concerned tests are
loongson-simd.c and loongson-shift-count-truncated-1.c in
In PR 64738 people complain about the fact that the gotools use
-static-libgo. It looks like I can set GOCFLAGS on the configure
command line, so remove -static-libgo. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2015-01-23 Ian Lance Taylor
PR go/64738
* Makefile.a
PR 64725 says that in some cases a finalizer test fails for gccgo. I
have not seen this myself but it's certainly possible, since gccgo's
garbage collection is not precise. This patch disables the finalizer
tests that require that a finalizer always run. Bootstrapped and ran
Go testsuite on x86_
How does this look as a potential fix for PR64703? I haven't made
many forays into gimple code, so even though this patch passes
bootstrap and regression testing on powerpc64-linux it's quite
possible this is the wrong place to change. If it does look to be OK,
then I'll fill out the targetm chan
PR 64573 points out that a line was somehow lost when merging from the
master library to libgo. This patch restores the line. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline.
Ian
diff -r b7495eb183c7 libgo/go/syscall/exec_unix.go
--- a/libgo/go/syscall/exec_
PR 64510 points out that the nilptr2.go test fails on targets that do
not support split stacks, because it passes a huge structure on the
stack. This patch avoids running the test on those targets.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu (where
the test is not skipped, but at
This patch to the gccgo manual clarifies that you should not strip Go
programs, as requested by PR 63565. I also added a note about using
cgo to interoperate between Go and C. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2015-01-23 Ian Lance Taylor
PR go/63565
* gc
On Fri, Jan 23, 2015 at 10:48:50PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote:
> > I understand that argument. But it is not what GCC actually does, nor
> > what I think it should do. Consider this program:
> >
> > --- 8< ---
> > int main(voi
The new Silvermont aswell and Broadwell model numbers are in
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
This patch updates host_detect_local_cpu to check new Silvermont, Haswell
and Broadwell model numbers. OK for trunk and
On Fri, Jan 23, 2015 at 06:37:01PM -0800, H.J. Lu wrote:
> The new Silvermont aswell and Broadwell model numbers are in
>
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
>
> This patch updates host_detect_local_cpu to check new
Hi Rainer,
Yes thanks I will work on fixing this. Let me know if I need to revert
the patch meanwhile.
regards,
Venkat.
On 24 January 2015 at 02:23, Rainer Orth wrote:
> Hi Venkat,
>
>> I committed the patch with the change log corrections you said.
>>
>> https://gcc.gnu.org/viewcvs/gcc?view=re
Igor noticed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043#c13
a regression caused by the option streaming patch on LTO SPEC scores.
While looking for posisble causes I noticed that x86_tune_cost is not properly
restored at cfun change. Fixed by the following patch.
Igor, does it fix the r
Hi Venkat,
> Yes thanks I will work on fixing this. Let me know if I need to revert
> the patch meanwhile.
I don't think this is urgent enough to justify reversion.
Thanks.
Rainer
--
-
Rainer Orth, Center for B
Hi Rainer,
I reused libgcc's "host_address" test and the patch passed normal
bootstrap in x86_64.
Can you please check if this is fine ?
regards,
Venkat.
On 24 January 2015 at 12:53, Rainer Orth wrote:
> Hi Venkat,
>
>> Yes thanks I will work on fixing this. Let me know if I need to revert
>>
78 matches
Mail list logo
