search for: mayurthebond

...the end of the function and should not be being relied upon by the calling code. I believe this is a red-herring to whatever your actual bug is. Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mayur Pandey [mayurthebond at gmail.com] Sent: 01 December 2012 11:13 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] operator overloading fails while debugging with gdb for i386 Problem seems not only with operator overloading, It occurs with struct value returning also. gdb while debugging expects the return valu...

...hrown error at all. it works fine with gcc. And the part of code which you mentioned is not getting hit at all. Maybe some difference in parsing is there. On Wed, Sep 25, 2013 at 5:29 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Mon, Sep 23, 2013 at 11:43 PM, Mayur Pandey <mayurthebond at gmail.com>wrote: > >> for the following code: >> >> struct X >> { >> X(); >> }; >> >> struct Y >> { >> operator X() const; >> }; >> >> X a = { Y() }; // reports error: no matching constructor for >>...

I'm not really an overload resolution expert, so I could be wrong. Anyway, please file a bug report (http://llvm.org/bugs/), and our overload resolution experts will take a look. :) -Eli On Wed, Sep 25, 2013 at 6:34 AM, Mayur Pandey <mayurthebond at gmail.com>wrote: > Actually it should have not thrown error at all. it works fine with gcc. > And the part of code which you mentioned is not getting hit at all. Maybe > some difference in parsing is there. > > > On Wed, Sep 25, 2013 at 5:29 AM, Eli Friedman <eli.friedma...

...being relied upon by the calling code. > > I believe this is a red-herring to whatever your actual bug is. > > Cheers, > > James > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf > Of Mayur Pandey [mayurthebond at gmail.com] > Sent: 01 December 2012 11:13 > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] operator overloading fails while debugging with gdb > for i386 > > Problem seems not only with operator overloading, It occurs with struct > value returning also. > >...

....loc 1 13 2 popl %esi popl %edi ret $4 But while returning int value clang returns with eax... as expect. Problem comes with when used struct/class Is the behaviour of llvm as per the standards or is this a bug?? On Thu, Nov 29, 2012 at 12:40 PM, Mayur Pandey <mayurthebond at gmail.com>wrote: > For the given test: > > class A1 { > int x; > int y; > > public: > > A1(int a, int b) > { > x=a; > y=b; > } > > A1 operator+(const A1&); > }; > > > A1 A1::operator+(const A1& second) > {...

For the given test: class A1 { int x; int y; public: A1(int a, int b) { x=a; y=b; } A1 operator+(const A1&); }; A1 A1::operator+(const A1& second) { A1 sum(0,0); sum.x = x + second.x; sum.y = y + second.y; return (sum); } int main (void) { A1 one(2,3); A1 two(4,5); return 0; } when the exectable of this code is debugged in gdb for i386, we dont get the

On 2 December 2012 08:12, Mayur Pandey <mayurthebond at gmail.com> wrote: > So is this just a coincidence for g++ that eax points to this address and > gdb prints the right value on the command print sum(one,two)?? The code is small, and the structure is probably set at the end of the block, so I think it's not that much of a coincidenc...

On Mon, Sep 23, 2013 at 11:43 PM, Mayur Pandey <mayurthebond at gmail.com>wrote: > for the following code: > > struct X > { > X(); > }; > > struct Y > { > operator X() const; > }; > > X a = { Y() }; // reports error: no matching constructor for > initialization of 'X' > X aa = Y(); // works fin...

for the following code: struct X { X(); }; struct Y { operator X() const; }; X a = { Y() }; // reports error: no matching constructor for initialization of 'X' X aa = Y(); // works fine clang when compiled with std=c++11 gives compilation errors as: testfile.C:11:3: error: no matching constructor for initialization of 'X' X a = { Y() }; // reports error: no

...; : The caller passes an additional hidden first parameter to the caller. That parameter contains the address at which the value being returned should be stored. On Mon, Dec 3, 2012 at 2:37 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 2 December 2012 08:12, Mayur Pandey <mayurthebond at gmail.com> wrote: > > So is this just a coincidence for g++ that eax points to this address and > > gdb prints the right value on the command print sum(one,two)?? > > The code is small, and the structure is probably set at the end of the > block, so I think it's not t...

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not...

Hi Mayur, > On 24 Nov 2014, at 07:00, MAYUR PANDEY <mayur.p at samsung.com> wrote: > In the assembly generated with O0, we are getting the "blx" instruction whereas with O1 we get "bx" (in 3.4.2 we used to get "blx" for both O0 and O1). > > Is this because of this patch: [llvm] r214959 - ARM: do not generate BLX instructions on Cortex-M CPUs