similar to: [LLVMdev] difference in function prologue generated with clang and gcc

http://bugs.freedesktop.org/show_bug.cgi?id=13491 Summary: 5min.com player causes assertion Product: swfdec Version: unspecified Platform: x86-64 (AMD64) URL: http://www.5min.com/ OS/Version: All Status: NEW Severity: blocker Priority: medium Component: library AssignedTo: swfdec at

Hi. I am trying to run LLVM with JIT on ARM processor (Android phone). Currently I have problems using external functions. Any call to external function crashes and gives me signal 11 (SIGSEGV) at some random address. I'm trying to run following C code: *** extern void add1(int* x); int main() { int a = 10; int b = 20; add1(&b); int c = a + b; return c; } *** It gives

Hello I have got the following problem: My Samba printer doesn't allow multiple copies, when trying to print from a client machine. (Unix printing works fine with multple copies). When I enter more than one copy into the "number of copies" field on a WinXP client machine, I get the error message "This printer cannot print the specified amount of copies. The amount of copies is

Hi, I am working on oVirt, and I am trying to run a VM with a network disk with ISCSI protocol ( the storage is on a Cinder server). Here is the disk XML I use: <disk device="disk" snapshot="no" type="network"> <address bus="0" controller="0" target="0" type="drive" unit="0" />

On Wed, Aug 02, 2017 at 05:47:31PM +0300, Fred Rolland wrote: >Hi, > >I am working on oVirt, and I am trying to run a VM with a network disk with >ISCSI protocol ( the storage is on a Cinder server). > >Here is the disk XML I use: > > <disk device="disk" snapshot="no" type="network"> > <address bus="0"

Nobody? These are repeating every 5 min on my DC2. No i dont care about the LostAndFound/deleted. [2017/05/15 16:52:32.848035, 0] ../source4/dsdb/repl/drepl_out_helpers.c:942(dreplsrv_op_pull_source_apply_changes_trigger) Failed to commit objects: WERR_GENERAL_FAILURE/NT_STATUS_INVALID_NETWORK_RESPONSE [2017/05/15 16:57:32.857425, 0] ../lib/ldb-samba/ldb_wrap.c:76(ldb_wrap_debug) ldb:

hi, I don't understand exactlly the difference among main function, prologue code, and call function. how the llvm JIT process them in details? the main function is a program start entry prologue code call yueqiang 2003/12/25

> I don't understand exactlly the difference among main function, prologue > code, and call function. I'm not sure that I understand your question. LLVM abstracts away target-specific information like function prologs and epilogs. If you are curious about the typical arrangement used by unix systems with _start and main, LLVM does not have that. Basically it uses 'main'

Chris Lattner wrote: >>I don't understand exactlly the difference among main function, prologue >>code, and call function. >> >> > >I'm not sure that I understand your question. LLVM abstracts away >target-specific information like function prologs and epilogs. > >If you are curious about the typical arrangement used by unix systems with

I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: _main: pushq %rbp Ltmp18: movq %rsp, %rbp Ltmp19: subq $320, %rsp Ltmp20: movl %ecx, -276(%rbp) I've tracked them back to emitPrologue in X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in

On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18: >> movq %rsp, %rbp >> Ltmp19: >> subq $320, %rsp >>

I don't see any references to them, that's why I brought it up... On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18:

On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > I don't see any references to them, that's why I brought it up... Interesting. Is this COFF? We may not emit the final debug info, but leave the ranges in. If they're filling up your symbol table then we likely need another type of assembler label for "COFF internal". -eric

Is there any reason why we couldn't skip emitting temporary labels in the COFF writer? I tried that and everything looks okay... On Aug 3, 2010, at 3:21 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > >> I don't see any references to them, that's why I brought it up... > > Interesting. Is this COFF? We may not emit the

Hello > The prologue length in .debug_line is 157 for clang generated one, whereas > it is 34 for gcc generated one. I am curious about the results of making > prologue generated by clang look similar with one generated by gcc. > Could anyone let me know why this difference exists and if it is for good > /better purposes than for gcc. ? 1. This is not function prologue length.

> Thanks for the reply. I have not specified optimization level explicitly > during compilation. For GCC default is O0 ie., no optimization. Do you mean > that clang uses other optimization level other than O0 ? No, here it's still -O0. However it makes no sense to compare the size of unoptimized code. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

Hello I am trying to run following dejaGNU testcases on Clang compiled output. /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/a080958f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201302201044290_44YDXKW4.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/a080958f/attachment.gif>

Reid Kleckner wrote: > I'm assuming this attribute won't affect inlining or other IPO in any > way, but you should probably mention that in the langref. To directly answer this, this is just a *mechanism* to implement linkonce_odr type linkage. This in itself does not imply in IPO restrictions, that should come directly from the linkage type. -- Sanjoy