similar to: [LLVMdev] bx instruction getting generated in arm assembly for O1

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

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

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

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

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

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

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

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

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 Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

I’m tying to run a rust application on armv4 architecture (arm720tdmi). Rust is using llvm to generate native code. Some programs are running well on the target but for more complex applications I receive a Illegal instruction : gdb disassembling the core dump file gives : 0x401e41dc <+0>: push {r11, lr} 0x401e41e0 <+4>: mov r11, sp 0x401e41e4 <+8>: sub sp, sp, #8

Hi Jonas, > here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thanks very much for working on this. It looks like a good starting-point, but there are a couple of issues with the patch at the moment. First, it only handles RelValue up to 22 bits (depending on how you count) in size. But on ARMv6T2 onwards the J1 and J2

On Tue, 31 Oct 2017 at 03:32, Mayur Dewaikar <mdewaikar at commvault.com> wrote: > Hi all, > > Are there any scale limitations in terms of how many nodes can be in a > single Gluster Cluster or how much storage capacity can be managed in a > single cluster? What are some of the large deployments out there that you > know of? > > The current design of GlusterD is not

Hi everyone, I'm working on some custom transformation passes that have the side-effect of significantly increasing the code size. While testing it on some larger, real-world code bases, I run into a linker error for armv7 thumb code. The particular error I get from ld64 is that "armv7 has no pc-rel bx thumb instruction." I've been able to reproduce the problem by taking a

Hi, This is regarding a TODO mentioned in getIdentityValue function in InstructionCombining.cpp file. //TODO: We can handle other cases e.g. Instruction::And, Instruction::Or etc. I wanted to know what could be the use cases of implementing these. When I tried implementing these and wrote test cases for the same, the test cases would be optimized in InstructionSimplify before hitting the code

Hi all, Are there any scale limitations in terms of how many nodes can be in a single Gluster Cluster or how much storage capacity can be managed in a single cluster? What are some of the large deployments out there that you know of? Thanks, Mayur ***************************Legal Disclaimer*************************** "This communication may contain confidential and privileged material for

splited patches and test cases mc-elf-thumbfunction-bit.diff: for 1 mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. mc-elf-cpu-xscale-attributes.diff: for 4. elf-thumbfunc.s: test case for 1 elf-thumbfunc-reloc.ll: test case for 2 and 3 elf-xscale-attribute.ll: test case for 4 On Fri, May 13, 2011 at 1:42 PM, Koan-Sin Tan <koansin.tan

Hi, On 12 March 2018 at 15:06, Son Tuan VU via llvm-dev <llvm-dev at lists.llvm.org> wrote: > But libc code is in ARM mode: That's very bad, because Cortex-M doesn't support ARM mode. I think your libc is broken. > As you can see, the call to srand is just a bl (Branch with Link), not a blx > (Branch with Link and Exchange instruction set), so I think something is >