similar to: [LLVMdev] Experimental fixes to CBackend

Hi, Please see the collection of test cases attached. To build everything execute make in the top directory. Files with logs show how compilation fails/succeeds, depending on patched/unpatched version of llvm. Could we setup this test suite as a regular test for C backend? Thanks, - D. 2011/8/5 Dmitry N. Mikushin <maemarcus at gmail.com>: > Hi, > > LLVM C backend as of revision

On Fri, Aug 5, 2011 at 10:33 AM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi, > > Please see the collection of test cases attached. To build everything > execute make in the top directory. Files with logs show how > compilation fails/succeeds, depending on patched/unpatched version of > llvm. > > Could we setup this test suite as a regular test for C

Dear all, I've also noticed C backend was removed a little bit... silently. In the end of March I only got open bugs closed by Benjamin Kramer in bugzilla, but they sounded like "decision is made". So the question is: it such silent removal a normal practice? In times of 3.0 release there were long discussions on what to drop and what to preserve, e.g. sparc backend, if I remember

Dear Jim and Owen, Thanks for replies, I only kindly suggest some discussion on the maillist in such cases. Just in general, nasty precedents sometimes happen, for example on IRC I've recently seen some commits to Objective C were requested to be reverted, because they were commited without any discussion. Here things are certainly not that hard, but the point is the same: it is always nice

Thank you for answering my E-mail. According to http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/047989.html, I open the link: https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.gpu.patch?root=kernelgen&view=markup https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.patch?revision=591&root=kernelgen&view=markup The result is: SCM Repository An Exception Has Occurred

Hi, First of all, please note: as of v3.1, C backend has been thrown away for being "buggy" and "unmaintained". Several months ago there was a similar question, and it was solved. Please see the patch attached here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/047989.html Best, - D. 2012/8/18 xiaoyaollvm <xiaoyaollvm at 126.com>: > In llvm3.0,I use the llc

Hi Dmitry, Where were you expecting notice to have been given? If I recall correctly, the obsolescence of the C backend was mentioned many times on this mailing list, and as Owen notes, in the release notes since 2.8. I'm not trying to be snarky. You were obviously genuinely surprised by its removal, and that makes me wonder if where the core open source devs are expecting people to look for

In llvm3.0,I use the llc to convert the IR to C code, But the code lack key words like "struct", Who can tell me how to modify the CBackend, 3Q ^-^ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120818/ee901cb1/attachment.html>

Okay, few issues here: First, i1 is used in the NVPTX back-end to map to the predicate (.pred) type. We definitely do not want to declare this type as illegal. The real issue is lack of complete support for this type. The PTX language places restrictions on what can be done with .pred registers, and it looks like the failure is here: kernelgen_hostcall.exit228: ; preds =

Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the

I think our test case demonstrates that requiring the array item being initialized to be constant is incorrect. NVPTX does not crash anymore and produces correct result with the following change: --- NVPTXAsmPrinter.cpp 2012-09-03 15:14:00.000000000 +0200 +++ NVPTXAsmPrinter.cpp 2012-09-04 15:47:17.859398193 +0200 @@ -1890,17 +1890,15 @@ case Type::ArrayTyID: case Type::VectorTyID: case

On Fri, Jun 29, 2012 at 2:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com> wrote: > Hi again, > > Kind people on #llvm helped me to utilize bugpoint to reduce the > previously submitted test case. For record, it code be done with the > following command: > > $ bugpoint -llc-safe test.ll > > The resulting IR is attached, and it is crashing in the same way. Is >

No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13

Hi Dan, Sean, Thanks for replies, So does it mean user is not expected to use any other stream for stdout, but outs()? Although there is a comment "If you don't want this behavior, don't use outs().", outs() is a static instance which always exists and creates problems, even if not used. - D. 2012/11/29 Dan Gohman <dan433584 at gmail.com> > On Wed, Nov 28, 2012 at

OK, thanks. For our project I implemented a similar workaround: extend each i1 memory item to i8 and load/store i1 to i8 with a type cast. Still, the issue in NVPTX remains. I don't know whether NVIDIA or community fellows have any reasonable priority to fix it (or at least put an NYI assertion!). It seems to be quite more complex, than implementing custom lowering handler, that's why

I see. And what's the purpose for outputting bitcode into *.o and *.a files? Do you want to perform an LLVM pass on linking step? 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hmm.. I didn't explain the problem completely last time. I am creating a > drop-in replacement for gcc and gfortran that runs an additional pass on the > bitcode before generating the native

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";

Does not work and same error even on old r157485 build. - D. 2012/11/10 Eli Friedman <eli.friedman at gmail.com>: > On Fri, Nov 9, 2012 at 5:01 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: >> I'm experiencing a weird issue during .ll file parsing, and I'm not sure if >> it's a bug in the .ll parser, or if I'm just not understanding

Hi Dmitry, >> did you declare i1 to be an illegal type? > > No. How? I think it will be considered illegal if you don't add it to any register class. Ciao, Duncan. > > 2012/6/30 Duncan Sands <baldrick at free.fr>: >> Hi Dmitry, >>> So instead of setOperationAction(ISD::STORE, MVT::i1, Expand); one >>> should probably do

Hi, Is it possible to make up a ConstantArray containing a "const char*" string and pass it directly to the function "char*" argument *without* creating a GlobalVaribable? I looked around and found the usual implementation is array->globalVar->gep. If we omit globalVar & gep, then the argument type would be [ i8 x N ], where N is set to the exact string length, and