search for: __typeof

Hi, This is my first post, sorry if not in the right format. I am stuck at a place where I have a code fragment that runs in normal gcc but fails when I give -fplugin=dragonegg.so extern int *testfunc(); extern __typeof (testfunc) testfunc __asm__ ("" "__GI_testfunc") __attribute__ ((visibility ("hidden"))); extern __typeof(testfunc) __testfunc; extern __typeof (__testfunc) __testfunc __asm__ ("" "__GI___testfunc") __attribute__ ((visibility ("hidden"))...

...<abyrupus at gmail.com> wrote: > Hi, > > This is my first post, sorry if not in the right format. > > I am stuck at a place where I have a code fragment that runs in normal gcc > but fails when I give -fplugin=dragonegg.so > > extern int *testfunc(); > > extern __typeof (testfunc) testfunc __asm__ ("" "__GI_testfunc") > __attribute__ ((visibility ("hidden"))); > > extern __typeof(testfunc) __testfunc; > > extern __typeof (__testfunc) __testfunc __asm__ ("" "__GI___testfunc") > __attribute__ ((visi...

...not been exposed via the linker (ld64/LLD). - http://blog.omega-prime.co.uk/?p=121 <http://blog.omega-prime.co.uk/?p=121> The musl code does the following which currently errors out saying aliases are not currently supported: #undef weak_alias #define weak_alias(old, new) \ extern __typeof(old) new __attribute__((weak, alias(#old))) and the macro is used internally like this: int __pthread_join(pthread_t t, void **res) { // implementation here } weak_alias(__pthread_join, pthread_join); The problem is the actual export used by clients is an alias and I want to maintain so...

...included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr.h:132: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:100:68: error: weakref declaration must have internal linkage extern __typeof(pthread_once) __gthrw_pthread_once __attribute__ ((__weakref__("pthread_once"))); In one of the development phorums, I found somebody saying that LLVM does not support gcc 4.1 libraries. Is that true? If yes, which libraries should I use, in case I would like to use llvm 2.9? R...

...l-libc.org/cgit/musl/tree/src/stdio/__stdio_exit.c> we > have: > > static FILE *const dummy_file = 0; > weak_alias(dummy_file, __stdin_used); > weak_alias(dummy_file, __stdout_used); > weak_alias(dummy_file, __stderr_used); > > weak_alias(old, new) is defined as: extern __typeof(old) new > __attribute__((weak, alias(#old))) > > This generates the following object file: > mspencer at mspencer-vm:~/Projects/test$ objdump -st > ../musl/src/stdio/__stdio_exit.o > > ../musl/src/stdio/__stdio_exit.o: file format elf64-x86-64 > > SYMBOL TABLE: &g...

...n musl __stdio_exit.c <http://git.musl-libc.org/cgit/musl/tree/src/stdio/__stdio_exit.c> we have: static FILE *const dummy_file = 0; weak_alias(dummy_file, __stdin_used); weak_alias(dummy_file, __stdout_used); weak_alias(dummy_file, __stderr_used); weak_alias(old, new) is defined as: extern __typeof(old) new __attribute__((weak, alias(#old))) This generates the following object file: mspencer at mspencer-vm:~/Projects/test$ objdump -st ../musl/src/stdio/__stdio_exit.o ../musl/src/stdio/__stdio_exit.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 000000000000000...

Hi all, I tried compiling an opencl kernel with intptr_t datatype. However it gives error by default using LLVM/Clang 3.2 for nvptx . To allow usage, I tried following typedefs ( by looking at tests in llvm sources ). typedef int intptr_t; and typedef __typeof( (int*) 0) intptr_t; Both definitions compiles the code, however gives following warning. warning: incompatible pointer to integer conversion assigning to 'int' from 'int *'; dereference with * Is it safe to use the above typedefs ? The generated code seems correct for x86 machine...

...-default.h:71:23: note: instantiated from: #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) ^ /usr/local/gcc-4.1/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu/bits/gthr-default.h:63:46: note: instantiated from: extern __typeof(type) name __attribute__ ((__weakref__(#name2))); ^ -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/

...LD). > > - http://blog.omega-prime.co.uk/?p=121 <http://blog.omega-prime.co.uk/?p=121> > > The musl code does the following which currently errors out saying aliases are not currently supported: > > #undef weak_alias > #define weak_alias(old, new) \ > extern __typeof(old) new __attribute__((weak, alias(#old))) > > and the macro is used internally like this: > > int __pthread_join(pthread_t t, void **res) > { > // implementation here > } > > weak_alias(__pthread_join, pthread_join); > > The problem is the actual expor...

...e appropriate declarations for "pthread_cancel" and its alias. This (mostly) matches the LLVM representation above. $ llvm-g++ -emit-llvm -E -o main.E.cpp main.cpp $ grep -Hn pthread_cancel main.E.cpp main.E.cpp:4414:extern int pthread_cancel (pthread_t __th); main.E.cpp:6058:static __typeof(pthread_cancel) __gthrw_pthread_cancel __attribute__ ((__weakref__("pthread_cancel"))); main.E.cpp:6075: = __extension__ (void *) &__gthrw_pthread_cancel; So, it looks like the CBE code generator is not producing correct output for the alias, since the LLVM bitcode appears co...

...?p=121 <http://blog.omega-prime.co.uk/?p=121> >>> >>> The musl code does the following which currently errors out saying aliases are not currently supported: >>> >>> #undef weak_alias >>> #define weak_alias(old, new) \ >>> extern __typeof(old) new __attribute__((weak, alias(#old))) >>> >>> and the macro is used internally like this: >>> >>> int __pthread_join(pthread_t t, void **res) >>> { >>> // implementation here >>> } >>> >>> weak_alias(_...