similar to: PATCH: fix pragma warning

--- src/libFLAC/bitreader.c | 4 ++-- src/libFLAC/bitwriter.c | 4 ++-- src/plugin_xmms/plugin.c | 2 +- src/share/utf8/charset.c | 1 + src/test_libFLAC++/encoders.cpp | 8 ++++---- src/test_libFLAC/decoders.c | 4 ++-- src/test_libFLAC/encoders.c | 8 ++++---- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/libFLAC/bitreader.c

All C and C++ files must include config.h --- src/libFLAC++/metadata.cpp | 4 ++++ src/libFLAC++/stream_decoder.cpp | 4 ++++ src/libFLAC++/stream_encoder.cpp | 4 ++++ src/plugin_xmms/charset.c | 4 ++++ src/plugin_xmms/configure.c | 4 ++++ src/plugin_xmms/fileinfo.c | 4 ++++ src/plugin_xmms/http.c | 4 ++++

I'd like to add a pragma support in llvm. I am thinking about using a llvm intrinsic to represent each pragma, such as llvm.pragma (metadata, ...) where metadata describes a pragma. So if an application has: #pragma p1 .. #pragma p2... for (...) The llvm IR would be llvm.pragma (metadata..) // for p1 llvm.pragma (metadata..) // for p2 llvm IR for "for

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

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.

--- COPYING.GPL | 43 +++++++++++----------- doc/Makefile.am | 6 +-- doc/Makefile.lite | 6 +-- examples/c/decode/file/Makefile.am | 6 +-- examples/c/decode/file/Makefile.lite | 6 +-- examples/c/decode/file/main.c | 6 +--

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

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

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.

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

Hi, I am trying to add an extension to OpenMP through a new pragma. I was wondering if there is any way I can declare a new pragma and define a set of rules for macro expansion or use PassManager in LLVM to expand the pragma. Thanks in advance. Regards, --Hari

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 way for implementing per-loop > pragma, or general pragma ? Suggestions/comments ? Hi Junjie, I don't know of anyone working on it, but it seems like a natural

Hi everyone, I wanted to assign a new pragma for loops in clang. Let's call it "#pragma XXX" which can be applied to any loop in the entire loop hierarchy. I added the support for my pragma by following the same steps as were being used in the default implementation of "unroll" pragma. But now, when I compile any program using clang to llvm IR it attaches the pragma

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 backend's job, not the front end's. If the only concern is that it is hard for pragma intrinsics to stay with their

A recent change to r-devel causes an R CMD check warning when a C file includes a "#pragma GCC diagnostic ignored" pragma: https://github.com/wch/r-source/commit/b76c8fd355a0f5b23d42aaf44a879cac0fc31fa4 . This causes the CRAN checks for the "corpus" package to emit a warning: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/corpus-00check.html .

Hi, all. I want to give programmer ability to tell LLVM that certain region of code is expected to get specialized optimization. So, I'm trying to make custom pragma to mark certain region of code and pass this information to LLVM, in the similar way that '#pragma clang loop unroll_count(N)' works. By tracking the framework of loop unroll pragma, I found out it works in the way below.

I'd like to add a custom #pragma directive in clang for research purposes. I'm familiar with the LLVM pass-writing interface but new to the rest of LLVM and clang. I've looked into Simone Pellegrini's work on a #pragma interface (https://github.com/motonacciu/clomp and http://llvm.org/devmtg/2013-04/pellegrini-slides.pdf), but I'm in no position to determine if this approach

Erik de Castro Lopo wrote: > JonY wrote: > > > Please do a link time test instead, I am not getting this error and > > would like to keep stack protector on. > > I'll write an m4 macro. I have attampted to write a macro that reliably detects the availability of stack smash protection. I currently have two configurations where my detection says that SSP is available

Hi folks, I needed to add -lstdc++ to the test to get them linked, otherwise libstc++ isn't linked in automatically. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174

+llvm-dev properly this time. On Fri, 10 Mar 2017 at 09:42 James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Reid, all, > > +llvm-dev as this RFC involves changes in Clang and LLVM. > > This RFC has stagnated and I think that's partially because the proposal > isn't particularly elegant and is light on details. We've been having a > rethink and have a