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

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

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 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

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

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

hi, when i build hello.cpp, it show following conflict: ----------------------------------------------------------- [yue at RH9 Shootout-C++]$ llvmg++ hello.cpp -o hello WARNING: Type conflict between types named 'struct._Unwind_Exception'. Src='{ ulong, void (uint, \4 *) *, uint, uint }'. Dest='{ ulong, void (ubyte, \4 *) *, uint, uint }' gccld: error linking in

Hi all, After successfully building llvm tools-only and cfontend, I went back to llvm directory and ran configure --with-llvmgccdir=$CFEINSTALL Unfortunately, at the end of the process I got the following configure: WARNING: ***** llvm C/C++ front end was not found, or does not configure: WARNING: ***** appear to be working. And I do have CFEINSTALL environment variable.... BTW, I have noticed

Hi Reid Spencer, > 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 "particular" version of 3.4, its > just 3.4ish. I also concur with him that you should file a bug and > attach the pre-processed source to it. You can get that with

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