Displaying 6 results from an estimated 6 matches for "__real".
Did you mean:
__read
2019 Jun 29
2
storage class 0 symbol is generated for a double constant in COFF-x86-64 object file
...et:
%50 = call i8* @my_function(i8* %48, double 2.000000e+00, double
2.000000e+00)
...
declare dllimport i8* @my_function(i8*, double, double)
By passing it to llc.exe, I find following symbol is declared in object
file's symbol table.
[10](sec 5)(fl 0x00)(ty 0)(scl 0) (nx 0) 0x00000000
__real at 4000000000000000
which has storage class 0, and it will lead to an error when I try to link
it with the rest of objects.
obj1.obj: Unrecognized storage class 0 for .rdata symbol
`__real at 4000000000000000'.
As comparison, I compile an equivalent c file (to my llvm asm file) using
clang-...
2019 Jul 02
2
storage class 0 symbol is generated for a double constant in COFF-x86-64 object file
...The command I use to produce PE object is:
llc.exe -filetype=obj -O0 sim_0.ll -o sim_0.obj
Reid Kleckner <rnk at google.com> 于2019年7月1日周一 下午1:45写道：
> I can't speak for what past versions of LLVM used to do, but I can see
> that today for this IR, we generate an external symbol __real at 40...:
>
> declare dllimport void @my_function(double, double)
> define i32 @main() {
> call void @my_function(double 2.000000e+00, double 2.000000e+00)
> ret i32 0
> }
>
> $ dumpbin -symbols t.o
> ...
> 006 00000000 SECT4 notype Static | .rdata
>...
2020 Jan 24
4
ORC JIT Weekly #2 -- COFF COMDAT Constants and Emulated TLS
Hi All,
This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2.
Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337):
When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to be discarded (roughly equivalent to the concept of a weak symbol). This posed two problems: (1) ORC had no idea about the (rough) mapping between COMDAT and Weak, and (2) did not support late in...
2009 Jan 07
3
[LLVMdev] LLVM optmization
..., ecx
$LN3 at TESTE:
; 20 : {
; 21 : varx = varx + parami + 1 ;
; 22 : vary = varx + nI;
; 23 : }
; 24 :
; 25 : return varx ;
; 26 : }
ret 0
_TESTE ENDP
_TEXT ENDS
PUBLIC ??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@ ; `string'
PUBLIC __real at 3ff0000000000000
PUBLIC _thread_call
EXTRN _printf:PROC
EXTRN __imp__GetCurrentThreadId at 0:PROC
EXTRN __fltused:DWORD
; COMDAT ??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seqt@
CONST SEGMENT
??_C at _0CG@LBAPCNHJ@?6?$CI2?$CJleu?5?$CFld?5threadid?5?$DN?5?5?$CFld?5seq...
2007 Feb 27
2
RES: asterisk-users Digest, Vol 31, Issue 115
...cro-test is called by
> >macro-first then ${MACRO_CONTEXT} = macro-first. Surely there's a way to
> >get the context directly from the Local channel itself?
> >
> >Cameron
>
> If nested macro calls are necessary, define an inheritable local variable,
> e.g., __real-context. Two _'s enables infinite inheritance. Hope this
> helps.
>
> Yuan Liu
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options v...
2007 Oct 22
4
[LLVMdev] OT: new here, dynamic/runtime compilation (in general)
...iciently infrequent that I can make due without them for the time being (namely: 'static', initialized structs, multi-prototypes, C99 style dynamicly-sized arrays, ...).
to 'add insult to injury' though, I implemented a few compiler extension features:
some partly derived from gcc (__real, __imag, ...);
some custom: builtin geometric vectors and quaternions (I do a lot of 3D stuff...);
..
I also have Garbage Collection, Dynamic Typing, and Prototype OO available as library features (note, I mean 'Prototype OO', in reference to the object system used in Self, and crudely imm...