search for: __attribute

...is actually quite new to me, so perhaps that's where I'm getting confused. Anyways, suppose I have a function that has a pointer to a GC-tracked object as a parameter and a collection can be triggered from this function, e.g. > > object* > f(object *some_obj) > { > object __attribute__((gcroot)) *new_obj; > new_obj = allocate_object(); > // A collection could have been executed at this point, > // and so some_obj might have become invalid > new_obj->child = some_obj; > return new_obj; > } To ensure that *some_obj isn't collected prematur...

...e packed into packed llvm structs. 2) it won't turn some that should be packed llvm structs into packed structs (e.g. strange ABI considerations force a field to be unaligned, not an attribute at the source level). Here's an example of #1: extern struct { int x; int y; int z; } __attribute((packed)) foos;; This should just be {int,int,int}, not <{int,int,int}>. The approach I'd like to see is: StructTypeConversionInfo should have a bool field "Packed" that is initialized to false. As fields are added to StructTypeConversionInfo, there are three cases: 1. GC...

The attached patch (gcc.patch) implements the gcc portion of packed types. I have only tested this on a few examples, so I may be missing some type conversions somewhere. The gcc patch requires llvm_extra.patch, not included in the previous emails. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm_extra.patch Type: text/x-patch Size: 1677 bytes

...lvm structs. 2) it won't turn some > that should be packed llvm structs into packed structs (e.g. strange ABI > considerations force a field to be unaligned, not an attribute at the source > level). > > Here's an example of #1: > extern struct { int x; int y; int z; } __attribute((packed)) foos;; > This should just be {int,int,int}, not <{int,int,int}>. no, consider struct foo { int x; int y; int z; } __attribute((packed)); struct {char c; struct foo f;} bar; sizeof(bar) == 13 if struct foo wasn't packed it's allignment would force a larger size for bar...

...> This seems lame, and maybe you need to change the header files inside VDSP++. > (This is pretty common for VDSP users to do when name space clashes occur > with open source software). > > Poking at the VDSP docs, says that it uses bank() rather than the industry > standard __attribute(section("foo")) - so you can't change that with a header > file change :( > > === From the VDSP manual ==== > Bank qualifiers can be attached to data declarations to indicate that the > data resides in particular memory banks. For example, > int bank(?blue?) *pt...

...e the dead strip roots ? There is a flag in the DefinedAtom to determine whether to deadstrip an atom, deadStripNormal, deadStripAlways, deadStripNever Question :- ************ a) What is the difference between deadStripNormal/deadStripAlways ? b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of...

...this invalidates memory: >> >> extern int pthread_mutex_lock (pthread_mutex_t *__mutex) >> __THROWNL __nonnull ((1)); >> >> THOWNL is attribute((nothrow)). > > Hm, this is actually a little worrying. Maarten, thoughts? I would > have assumed there'd be a __attribute__((some_magic_thing)) in there. In general things don't get optimized across function calls, except in case of inlinable functions. And for compiler attributes it's the opposite,__attribute__((const)) and __attribute((pure)) can be used to indicate some kind of safety to optimize across fu...

...e compiler. > > Ah, sorry. Because the compiler might not know it yet. Consider linking > code compiled with -fPIC into the main binary, either using PIE or not. Right, but the issue we're discussing here, is why GCC chooses to not optimize a variable like this: static __thread int __attribute((tls_model("global-dynamic"))) x; even if it could (e.g. when compiled without -fpic). We're trying to figure out if there's a good reason for this, and if we want to mimic that behaviour in LLVM, or if we should just take the tls_model attribute as a starting point, and choose...

Hi Jean-Marc, As I told you, bank is a reserved keyword in Analog Devices compiler for Blackfin architecture. So we need to change the variables named bank to something else. Here's a patch that changes bank to bnk in the 3 concerned files. (Hope the format is OK) About my previous problems with the Blackfin: -> strange block repetition that could be cancelled by the AEC I was busy

I have the following code: static inline void foo() __attribute((always_inline)); int a; static inline void foo() { a++; } int main(int argc, char *argv[]) { foo(); return 0; } However, the code generated by llvm 2.4 toolchain does not inline this function. opt retains the function call. Here is the output when I try to compile with -debug-only=inline...

Hello, Another question about the more esoteric parts of C. Is there any way to get dragonegg to handle c function aliases or is there a way to get around this? For example, I've got a simple file: int foo(int x) { return x; } extern typeof(foo) foo2 __attribute((alias("foo"))); Compiling with vanilla gcc I end up with two symbols: foo and foo2 which both refer to the same function. When I compile through dragonegg I only get a symbol for foo. Thanks. -- gregory malecha http://www.people.fas.harvard.edu/~gmalecha/ -------------- next part ---...

Hi Nick, >> b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ? > In mach-o it *is* passed on to the linker by the compiler. It is the N_NO_DE...

On 01/09/2013 01:19 PM, Sean Silva wrote: > On Wed, Jan 9, 2013 at 4:14 PM, reed kotler <rkotler at mips.com> wrote: >> Does anyone know offhand where this gets added to clang and where the hook >> for processing >> in llc is? >> >> I think that this code has changed recently. > There's

...ternalsManual.html#how-to-add-an-attribute>. >> If that's not up to date please let me know. >> >> -- Sean Silva > > Thanks. > > Not sure I understand the purpose of InheritableAttr . InheritableAttr is related to our behavior for testcases like the following: __attribute((fastcall)) int f(void); int f(void); (More generally, it looks like your attributes are very similar to the fastcall attribute; just do what we do for the fastcall attribute, and it'll be roughly correct.) -Eli

...ay know that although the data is not static - it is still reachable with a near address.  For instance, if it's in another source file that is statically linked to a resulting object file with size < 2GB. Is there a way to tell clang to assume that a piece of data is near, such as extern __attribute((assume_near))__ int x; and generate code accordingly (i.e. not via GOT access). Thanks in Advance.

...-attribute>. >>> If that's not up to date please let me know. >>> >>> -- Sean Silva >> Thanks. >> >> Not sure I understand the purpose of InheritableAttr . > InheritableAttr is related to our behavior for testcases like the following: > > __attribute((fastcall)) int f(void); > int f(void); > > (More generally, it looks like your attributes are very similar to the > fastcall attribute; just do what we do for the fastcall attribute, and > it'll be roughly correct.) > > -Eli Cool. What about let Subjects = [Function]; ?...

...ence between deadStripNormal/deadStripAlways ? The idea for deadStripAlways is that some file formats have atoms which are optional and should only be kept by the linker if actually used by something. I do not plan to use it for mach-o. > > b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ? In mach-o it *is* passed on to the linker by the compiler. It is the N_NO_DEAD_ST...

...ork properly - perhaps > correct the definition of my 'store' instructions, or set a data-layout for > a struct type somewhere? Your code has undefined behavior; you're just getting lucky if it works anywhere. (I can look up the standard reference if you're interested.) Try __attribute((aligned)) on the array. -Eli

...> These structs are carefully designed not to have any padding. >> > >> > ...on every compiler and OS combination that QEMU builds for? > Yes. All the way back to EGCS and before. > GCC has been like this for many many years. I would still prefer to have QEMU_PACKED (or __attribute((__packed__)) in the kernel). >>> > > And if there was a bug and there was some padding, we still >>> > > can't fix it with PACKED because this structure >>> > > is used to interact with the guest code which does not >>> > > have the...

...y. Because the compiler might not know it yet. Consider linking > > code compiled with -fPIC into the main binary, either using PIE or not. > > Right, but the issue we're discussing here, is why GCC chooses to not > optimize a variable like this: > > static __thread int __attribute((tls_model("global-dynamic"))) x; > > even if it could (e.g. when compiled without -fpic). > > We're trying to figure out if there's a good reason for this, and if > we want to mimic that behaviour in LLVM, or if we should just take the > tls_model attribute as...