similar to: [LLVMdev] c++ frontend bugs

I've encountered a few bugs including ICE and reject-valid when compiling a program with llvmg++ which compiles fine with standalone g++. Should I report those to your bugzilla or is it likely that these bugs are gcc bugs in the version of gcc you're using? if so, are there any plans to port the frontend to a newer gcc? (gcc 4.0 will be out in a few weeks) the versions: llvm 1.4 from

Markus F.X.J. Oberhumer schrieb: > The reason behind this is that llvm-gcc is based on a pre-3.4 snapshot > ("3.4-llvm 20030924") then it's not unlikely that these are llvm bugs since my code also compiles with gcc 3.3 filed PR 551 and 552 -- Stefan Strasser

Markus F.X.J. Oberhumer wrote: > Hello folks, > > with the small patch attached below the whole llvm toolchain (llvm & llvm-gcc) > will compile and run under AMD64 Linux in native 64-bit LP64 mode. > > This means that compilation, bytecode management and CWriter output all work > as expected. Of course there is no JIT, and the bytecode interpreter is still > very

On Mon, 28 Jun 2004, Surupa Biswas wrote: > I am at the University of Maryland, College Park, working with Prof. > Rajeev Barua. Someone just told me that LLVM includes a C++ to C > source-to-source compiler. I was hoping you could tell me something about > that - I am trying to run some C++ benchmarks on the Motorola Mcore > simulator and my compiler only has a C front-end. Yup,

in case you're interested in having llvm in debian sarge: it was removed today. I don't know why, but you might want to find out because sarge is in freeze phase for release next month. regards, -- Stefan Strasser

Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I''d ask some official kernel maintainer for review and to push this into linux-next so that it

On Nov 19, 2004, at 9:25 PM, Mohd-Hanafiah Abdullah wrote: > Dear Dr Vikram: > > I need to know how to invoke llvmg++ so that it generates C code. Here's how you can do a single file (i.e., an unlinked executable): llvmg++ -c infile.cpp -o - | llc -march=c -o infile.cbe.c Reid might be able to tell you how to do it with a single command using the llvmc tool. In future, please

Markus, We are in the process of trying to make this happen. It's a matter of getting all the duckings lined up in a row. We finally resigned ourselves to the fact that we can't cvs/svn and maintain the sanity of FSF branches, Apple branches and LLVM branches. So, over the next few working days we are going to set up a nightly cron script to checkout the latest and greatest

Hi, I'm just getting back to working on the cfe debug info after a brief hiatus. It appears that the appropriate place to be inserting stoppoints is starting in llvm_expand_stmt, using STMT_LINENO(t) . If that's not the best place, comments would be appreciated. Using the debug_hooks seems to be a non-starter, because they're called during rtl generation, which apparently isn't

On Fri, 11 Mar 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Thu, 10 Mar 2005, Andrew Lenharth wrote: >> >>> yes, so this happens on anything that uses a struct for va_list (like >>> alpha). I am currently working on fixing this. if you look at the last >>> patch to the alpha portion of llvm-gcc, you can see a quick hack to work

On 2020-06-16 20:32 +0200, Alexander Strasser wrote: > On 2020-06-16 12:37 -0000, Stuart Henderson wrote: > > On 2020-06-15, Alexander Strasser <eclipse7 at gmx.net> wrote: > > > I had some imap crashes (sig11) starting at the end of 2019 after > > > an upgrade of dovecot. > > > > > > I found out, that I didn't have any problems using version

Conditional Inference Procedures in a Permutation Test Framework The `coin' package implements a general framework for conditional inference procedures, commonly known as permutation tests, theoretically derived by Strasser & Weber (1999). The conditional expectation and covariance for a broad class of multivariate linear statistics as well as the corresponding multivariate limiting

Conditional Inference Procedures in a Permutation Test Framework The `coin' package implements a general framework for conditional inference procedures, commonly known as permutation tests, theoretically derived by Strasser & Weber (1999). The conditional expectation and covariance for a broad class of multivariate linear statistics as well as the corresponding multivariate limiting

Hi Markus, Thanks for this interesting patch! It looks okay to me, but our C/C++ Front End guru is away right now. I would rather defer to him on this patch. He might not get to it until next week so I just wanted to let you know that there might be a bit of a delay before this patch hits mainline. I've already committed your configure changes. Reid. On Wed, 2004-12-22 at 21:42, Markus

On Sat, May 14, 2005 at 02:18:26AM +0200, Stefan Strasser wrote: > in case you're interested in having llvm in debian sarge: it was > removed today. I don't know why, but you might want to find out > because sarge is in freeze phase for release next month. Possibly because of these: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=llvm I addressed the first one and fixed it in

Hi! On 2020-06-16 12:37 -0000, Stuart Henderson wrote: > On 2020-06-15, Alexander Strasser <eclipse7 at gmx.net> wrote: > > I had some imap crashes (sig11) starting at the end of 2019 after > > an upgrade of dovecot. > > > > I found out, that I didn't have any problems using version v2.3.8, > > but any version v2.3.9 and higher would trigger the crashes.

Adam, I recant my previous message. I built FreeType with GCC not LLVMGCC by accident (I shoulda checked!). The thing is, FreeType's makefiles don't respect environment variables. So, I did this: CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure make and was able to reproduce the problem. Not sure what's up with that but as Misha pointed out, llvmgcc isn't any

hi, when build test echo.cpp using "llvmg++ echo.cpp -o echo" it create an echo file, contain: ------------------------------------- [yue at RH9 Shootout-C++]$ cat echo #!/bin/sh lli \ -load=/usr/lib/libm.so \ $0.bc $* --------------------------------------- and using "llvmgcc echo.cpp -o echo-c", it creates an echo-c file, contain:

hi, I try to build hello.cpp using both llvmg++ and GNU g++, the generate llvm bytecode's size is about 960K, and the size of binary code generated by g++ is only 13K. Could anyone explain the difference between the two result? BWT: I rebuild the cfrontend in RH linux9.0, but when I build the hello.cpp the llvmG++ reports warnings too, it shows: ----------------------------- [yue at RH9

I will definately look into this tonight and see if it is a problem with my recent patch. On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote: > >>Follow up: After removing the dangling symlink the problem now looks: > >> > >>-march=c((anonymous