search for: pragmas

Follwoing errors are shown while installation. Any quick help will be highly appriciated. config.c: In function `init_server_dir': config.c:217: warning: right shift count >= width of type config.c: In function `init_paths': config.c:256: warning: unsigned int format, uid_t arg (arg 3) mmap.c: In function `try_mmap_fixed': mmap.c:107: warning: implicit declaration of function

Hi Chris, Thanks. I will see what I can do for this. Junjie On Wed, May 19, 2010 at 3:45 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > >> Many compilers support per-loop pragma, such as loop unrolling (ie >> #pragma unroll=2).  Is there any LLVM project/effort going on >> in this area ? What is the expected

...r p2 llvm IR for "for (...)" In this way, the pragma handling is quite general (for example, it can be used to support frequency hint for a branch, etc). And it should be easy for any frontend to generate. A possible issue might be that optimizations might make the association between pragmas and their loops (in this case) less obvious. Any suggestions/ideas ? Junjie On Wed, May 19, 2010 at 4:31 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Hi Chris, > > Thanks. I will see what I can do for this. > > Junjie > > On Wed, May 19, 2010 at 3:45 PM, Chris Lattner...

Thanks Reid/Jonathon for your replies. Reid, An important case against module level flags is that it wont allow changing or resetting section names e.g. int a; #pragma clang section bss = "xyz" int b; In case above, users would like to see only 'b' placed in 'xyz' and not 'a' as well. Link pointed to by Jonathon seems to require same behavior.

...: > > #pragma bss_seg('.bss.mybss') > int i; // Microsoft extension will put i in .bss.mybss > int j = 0; // Microsoft extension will put j in .data, whereas we really > need it in .bss.mybss > > So to specifically answer your questions: > > In ARM Compiler 5, all pragmas are pushable and poppable. Clang doesn't > have this feature generally yet, but when/if it does, I don't see why this > pragma shouldn't be affected. So yes, we should consider it pushable and > poppable. > > I think the only reasonable behaviour under LTO must be that th...

...4. tries to outline a possible workflow for implementing this > new feature. > > I am looking for any feedback or suggestions etc. > > Thanks! > Andrea Di Biagio > SN Systems Ltd. > http://www.snsys.com > > 1. Description > ============== > The idea is to add pragmas to control the optimization level on functions. > > A similar approach has been implemented by GCC as well. > Since GCC 4.4, new function specific option pragmas have been added to > allow > users to set the optimization level on a per function basis. > > http://gcc.gnu.org/onl...

...I find myself in the same situation as I am with GCC as they won't be accepted upstream? Especially since for most of them we already/can have alternative implementations using __attribute__ and other approaches more in line with clang extensions. First things I would like to explain are the pragmas. Most CCRL pragmas have a trait which is quite unusual: the first parameter is function or a variable name, for example in order to declare a interrupt functions while in GCC I do: void inter ( void ) __attribute__((interrupt)); In CCRL this is declared the following way: #pragma interrupt inter vo...

...gt;>>> so it also links in OLE32. I believe that we usually only use > >>>> #pragma(lib) to signal that non-standard libraries need to be linked > >>>> in, otherwise every source file in an archive would wind up with an > >>>> unwieldy number of pragmas for all its imports, or you would have to > >>>> manually maintain that list in some common header file. I don't think > >>>> that the pragma(lib) for advapi32.lib should be there either, FWIW, > >>>> but I don't know that we've ever had a ha...

...consumes LLVMSupport.lib and >>> so it also links in OLE32. I believe that we usually only use >>> #pragma(lib) to signal that non-standard libraries need to be linked >>> in, otherwise every source file in an archive would wind up with an >>> unwieldy number of pragmas for all its imports, or you would have to >>> manually maintain that list in some common header file. I don't think >>> that the pragma(lib) for advapi32.lib should be there either, FWIW, >>> but I don't know that we've ever had a hard-and-fast rule for this &...

pragma GCC diagnostic is a gcc 4.6+ feature, compilation fails with older compilers: inspect-fs-windows.c: In function 'map_registry_disk_blob': inspect-fs-windows.c:502: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:503: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:505: error: #pragma GCC diagnostic not allowed inside

...rate=50Hz but still I am getting the following messages, Drop: 17458 dynamic variable drops Drop: 3426 dynamic variable drops with non-empty dirty list and the amount data that my D script is reporting, is gradually dropping. This means that the tuning that I am doing using the above #pragmas is not sufficient to address this particular problem. Is this a known problem ? Is there a workaround/fix to address this problem ? Though my D script keeps running, it becomes useless after some time on such a heavily loaded system. -- This message posted from opensolaris.org

+cfe-dev as the discussion is now biased toward C standard. I'm not sure what problem you see here. In default mode, i.e. > when there is no "#pragma STDC FENV_ACCESS on" in effect, > then the compiler can always assume that the default rounding > mode is in effect. Well, if #pragma STDC FENV_ACCESS on is not in effect, that means > that the user has promised that at

Many compilers support per-loop pragma, such as loop unrolling (ie #pragma unroll=2). Is there any LLVM project/effort going on in this area ? What is the expected way for implementing per-loop pragma, or general pragma ? Suggestions/comments ? Thanks Junjie

journal.c: In function 'guestfs__journal_get': journal.c:120:9: error: #pragma GCC diagnostic not allowed inside functions journal.c:121:9: error: #pragma GCC diagnostic not allowed inside functions journal.c:123:9: error: #pragma GCC diagnostic not allowed inside functions make[3]: *** [libguestfs_la-journal.lo] Error 1 Signed-off-by: Olaf Hering <olaf@aepfle.de> --- Not compiled.

Hello, Thank you very much for your reply. I have configured bind using the dlz backend and these are the results. named log: Mar 15 09:39:41 neptuno named[13166]: sizing zone task pool based on 6 zones Mar 15 09:39:41 neptuno named[13166]: Loading 'AD DNS Zone' using driver dlopen Mar 15 09:39:42 neptuno named[13166]: samba_dlz: started for DN DC=pragma,DC=com,DC=co Mar 15 09:39:42

Hello, Sorry for the few details. rsync: rsync -h -a -v /usr/local/samba/var/locks/sysvol/pragma.com.co/ root at server2:/usr/local/samba/var/locks/sysvol/pragma.com.co/ first dc smb.conf: [global] tls verify peer = no_check ldap server require strong auth = no netbios name = NEPTUNO realm = PRAGMA.COM.CO server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd,

...lementing this >> new feature. >> >> I am looking for any feedback or suggestions etc. >> >> Thanks! >> Andrea Di Biagio >> SN Systems Ltd. >> http://www.snsys.com >> >> 1. Description >> ============== >> The idea is to add pragmas to control the optimization level on functions. >> >> A similar approach has been implemented by GCC as well. >> Since GCC 4.4, new function specific option pragmas have been added to >> allow >> users to set the optimization level on a per function basis. >> &gt...

On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges requires that the front end to build > loops, which is an > additional task for the front end. And this task is really a

...ons. So, for instance, clang.exe consumes LLVMSupport.lib and > so it also links in OLE32. I believe that we usually only use > #pragma(lib) to signal that non-standard libraries need to be linked > in, otherwise every source file in an archive would wind up with an > unwieldy number of pragmas for all its imports, or you would have to > manually maintain that list in some common header file. I don't think > that the pragma(lib) for advapi32.lib should be there either, FWIW, > but I don't know that we've ever had a hard-and-fast rule for this > sort of thing. >...

...the definition of per-function optimizations; - Section 4. tries to outline a possible workflow for implementing this new feature. I am looking for any feedback or suggestions etc. Thanks! Andrea Di Biagio SN Systems Ltd. http://www.snsys.com 1. Description ============== The idea is to add pragmas to control the optimization level on functions. A similar approach has been implemented by GCC as well. Since GCC 4.4, new function specific option pragmas have been added to allow users to set the optimization level on a per function basis. http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Op...