similar to: [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 value in eax, gcc does returns in eax, But Clang returns in edx(it can be checked in gdb by printing the contents of edx). Code(sample code) struct A1 { int x; int y; }; A1 sum(const A1 one, const A1 two) { A1 plus = {0,0}; plus.x = one.x + two.x; plus.y

Hi, Structures are passed by pointer, so the return value is not actually in eax. That code gets transformed into something like: void sum(A1 *out, const A1 one, const A1 two) { out->x = one.x + two.x out->y = one.y + two.y } So actually the function ends up returning void and operating on a hidden parameter, so %eax is dead at the end of the function and should not be being relied

Hi, As you told that function ends up returning void, I just confirmed it in the IR, the function is defined as: define *void* @_Z3sum2A1S_(*%struct.A1* noalias sret %agg.result*, %struct.A1* byval align 4 %one, %struct.A1* byval align 4 %two). But when i checked the register values in g++, eax contains an address of stack, which points to the value (object) returned by sum. That is if we

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 coincidence. Regardless of the specific value on that

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.friedman at gmail.com>wrote: > On Mon, Sep 23, 2013 at 11:43 PM, Mayur Pandey <mayurthebond at gmail.com>wrote: > >> for the following

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

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 printing correct debug information (or is

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

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

Hi, I was going through this issue along with the standards. What the standard states is(reference: http://www.sco.com/developers/devspecs/abi386-4.pdf): If a function returns a structure or union, then the caller provides space for the return value and places its address on the stack as argument word zero. In effect, this address becomes a ‘‘hidden’’ first argument. Having the caller supply the

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 fine > > > clang when compiled

In matcher/expandweight.cc we have: OmExpandBits operator+(const OmExpandBits &bits1, const OmExpandBits &bits2) { OmExpandBits sum(bits1); sum.multiplier += bits2.multiplier; sum.rtermfreq += bits2.rtermfreq; // FIXME - try to share this information rather than pick half of it if (bits2.dbsize > sum.dbsize) { DEBUGLINE(WTCALC,

On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > > Did you get anywhere with the function attribute? Having isolated the > next boot failure to "it goes away if I compile io_apic.c without > retpoline", bisecting it per-function would help to further delay the > bit where I actually have to start *thinking*... It's mp_register_ioapic(), and only when

I spent some time digging into a Valgrind report of uninitialized values in LLVM r287520 built using itself. (One of quite a few such reports that comes up during a "make check".) I could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon

Just want to emphasize that on x86-64 and using Valgrind: LLVM compiled with LLVM gets 360 unexpected test fails LLVM compiled with GCC gets 22 unexpected test fails Of course I don't know how many of these are caused by this bitfield speculation issue. John On 11/21/2016 10:48 PM, regehr via llvm-dev wrote: > Alright, here's what seems to be happening... > > The testcase

On 02/17/2016 07:23 PM, Tony Kelman via llvm-dev wrote: > Richard Pennington via llvm-dev <llvm-dev <at> lists.llvm.org> writes: > >> I use ELLCC to cross compile all the tools for various Linux targets and >> for Windows. Yesterday, after updating the LLVM sources, I got the >> following error when cross building for MinGW: > I haven't seen this exact

Hi, I recently switched over to using cmake to build my clang/LLVM based ELLCC cross development project (http://ellcc.org). I also recently updated to LLVM svn version 258915 from 258477. I use ELLCC to cross compile all the tools for various Linux targets and for Windows. Yesterday, after updating the LLVM sources, I got the following error when cross building for MinGW: [ 3%] Built

On Fri, 2018-02-09 at 12:54 +0000, David Woodhouse wrote: > On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote: > >  > > Did you get anywhere with the function attribute? Having isolated the > > next boot failure to "it goes away if I compile io_apic.c without > > retpoline", bisecting it per-function would help to further delay the > > bit where I

Hi, > Glad that works for you, but it means that if the 32-bit cost > computation overflows, we won't be told about it. I think the right > thing is to make sure the computation saturates at 30 bits instead of > overflowing. Am I going to talk myself into overloading operator+ ? is this problem really real? Or has LLVM been miscompiled? The two people who have reported

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses