similar to: 32/64-bit Library Sharing and Placement

Hi, [This is a follow-up to the "New version of Rtools for Windows" thread in January, but I just subscribed and don't know how to reply to an old thread -- my apologies.] I was able to use the nuwen distro to build a gcc 4.9.2 toolchain and use it to build the latest R-patched with it. Below are some notes about what I did; I hope they will be useful for keeping Rtools

Just in case someone is having similar problems and/or following this thread, here's my final "solution" (at least, for now). In my bash build script, prior to configure, I set the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to empty strings, and then set some other environment variables instead: export C_INCLUDE_PATH= export CPLUS_INCLUDE_PATH=

As someone that has worked with both gcc and llvm, One thing about gcc that drives me bat-guano-crazy is that First you check out gcc, try to build it, and find that you also Need mpc, so you check that out and try to build it, and Find out you also need gmp, so you check that out and try To build it, and find out that you also need mpfr, ..... IE I'm in favor of a mono-repository. Also

On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as far as I can tell). All TUs are compiled with -O3. This is also > an instance where we don't actually speculate an inline function,

Yest. thanks. I just resolved this error by installing MPFR, MPC and GMP(by the way, these are not listed as prerequisites in the website.). But other errors come: /home/xxx/llvm/tools/dragonegg/src/TypeConversion.cpp: In function > ‘llvm::FunctionType* ConvertArgListToFnType(tree_node*, > llvm::ArrayRef<tree_node*>, tree_node*, bool, llvm::CallingConv::ID&, >

Hi Eric, here is my -emit-llvm -S -v output: Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.5.1/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

The current dragonegg trunk svn used under FSF gcc 4.5.2 with llvm 2.9 is able to bootstrap FSF gcc 4.5.2 itself on x86_64-apple-darwin10... Using built-in specs. COLLECT_GCC=gcc-mp-4.5 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.2/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5.2/configure --prefix=/opt/local --build=x86_64-apple-darwin10

Looks like something wonky with DragonEgg. Duncan? -eric On Mar 21, 2011, at 7:05 PM, stackunderflow wrote: > > Hi Eric, > > here is my -emit-llvm -S -v output: > > Using built-in specs. > COLLECT_GCC=gcc-4.5 > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.5.1/lto-wrapper > Target: i686-linux-gnu > Configured with: ../src/configure -v

> On Sep 2, 2016, at 12:33 PM, Dimitry Andric via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 16 Aug 2016, at 00:12, Lawrence, Peter via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> As someone that has worked with both gcc and llvm, >> >> One thing about gcc that drives me bat-guano-crazy is that >> First you check out gcc, try to

Hi Eric, > Looks like something wonky with DragonEgg. you need to use -fplugin-arg-dragonegg-emit-ir or -flto with dragonegg, not -emit-llvm. Also, you currently have to use -S (getting human readable IR) rather than -c because with -c gcc will run cc1 with -S (getting human readable IR) then pass the result to the system assembler which of course barfs. This is documented on the web-page

> On Sep 3, 2016, at 3:04 PM, Patrice Kouame <pkouame at mac.com> wrote: > > > +1 for keeping it separate. Can you clarify what you referring to specifically? This sub thread (the last 4 messages) started with a mention of GCC dependencies. It is not clear to me how to relate to llvm now. Mehdi > > One can easily set up a git subproject structure if the need is

> On Sep 3, 2016, at 6:05 PM, Patrice Kouame <pkouame at mac.com> wrote: > > Someone mentioned llvm in a mono repository below… Right, we actually have a proposal to take what is in the current SVN repo here: http://llvm.org/svn/llvm-project/ and migrate this to a single repository. I was not sure if you were referring to this proposal (monorepo) or to the recent emails about

Hello all, With some help from Duncan through IRC, I just succeeded in building the dragonegg GCC plugin on Snow Leopard. I first installed LLVM 2.7, and I'm using the dragonegg-2.7 release available on the LLVM website [1] in combination with the 4.5.0 release of GCC. Below is an outline of the steps required to get it to work, which is hopefully of use to others. *) Build GCC-4.5.0 Next

>> /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/plugin/include/real.h:27:18: >> fatal error: mpfr.h: No such file or directory > > I did some search but found few relevant results. > Any idea what's going on? Do you have MPFR installed? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi, When I tried to compile Dragonegg using the SVN trunk code, I encountered failure with error message: In file included from > /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/plugin/include/rtl.h:28:0, > from /home/xxx/llvm/dragonegg/src/Convert.cpp:63: > /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/plugin/include/real.h:27:18: > fatal error: mpfr.h: No such

On 2015-12-18 02:29, Simon Urbanek wrote: > Michael, > > I got access to PDP AIX so I can try to replicate your problem. Can you, please, share exactly your setup - AIX version and well as how exactly you installed the compilers (=where from)? I can then try to replicate it. AFAICS there is no official binary for gfortran nor gcc 4.7 so it must be some 3rd party - which could also be a

On 08/03/2015 10:02 PM, Hsiu-Khuern Tang wrote: > Hi, > > [This is a follow-up to the "New version of Rtools for Windows" thread > in January, but I just subscribed and don't know how to reply to an > old thread -- my apologies.] I am planning to put a new Rtools online today that uses a different build of gcc 4.9.2. I will be concentrating on getting it to work

On 10/20/2012 05:38 PM, Jack Howarth wrote: > Duncan, > Is the documentation for using Polly support in dragonegg correct? I built llvm/polly/dragonegg > using the documentation at http://polly.llvm.org/example_load_Polly_into_dragonegg.html > with... > > GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config ENABLE_LLVM_PLUGINS=1 make

I'm continuing this here in llvm-dev since the thread was started here, but, in hindsight, it may have been better in cfe-dev, because the problem seems to be related to clang. I turned on "verbose" mode in make (VERBOSE=1 TOOL_VERBOSE=1) and found that it is clang, not gcc, that is being used at this point in the make. Based on the command issued (particularly with the --sysroot

Hi, I am trying to write code in C for an R package. I need high precision in the form of the mpfr and gmp packages. I have installed mpfr and gmp under the instructions of the following website http://pauillac.inria.fr/cdrom_a_graver/prog/pc/mpfr/eng.htm and I get no errors. I have put the header files (mpfr.h and gmp.h) in the folder C:\Program Files\R\R-2.13.0\include; allowing my c code to