similar to: Programmer types

Hi, Can anyone advise me on how to compile R with Portland Group compiler on a Opeteron machine with Red Hat Enterprise Linux WS release 4 installed? I've edit config.site file to pick portland group compilers instead of gcc. Here is the list of modified flags: CC=/usr/pgi/linux86-64/6.0/bin/pgcc CFLAGS='-g -O2' CPPFLAGS='-I/usr/pgi/linux86-64/6.0/include

Hi List, I've run into a library problem I believe might be related to the portland group compiler, and / or the libs on CentOS. Essentially what is happening is the primary executable I'm trying to run is failing under mpi. Here's the output from the command (which would be the same as the script calling it) $ /usr/local/mpich/bin/mpirun -machinefile machines.LINUX -np 2

Hi, I built R with Portland Group compiler, but I noticed one thing that when I ran configure for the first time on AMD machine, I got the following error: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. so I tried to set host=x86_64-unknown-linux-gnu,

Hi All, While attempting to build R-patched using the Portland Group compiler suite on our dual Opteron 250 box running Scyld 29cz5 (based on RH, kernel 2.4.29), I get: make[5]: Leaving directory `/home/andy/Rbuild/R221-pgi/src/library/tools/src' make[5]: Entering directory `/home/andy/Rbuild/R221-pgi/src/library/tools/src' pgcc -I../../../../include -I/include -I/include/CC -fpic

Dear R-devel, [I'm not sure if this is appropriate for R-devel. If not, I'm more than happy to move it to R-help.] As those of you who saw my post on R-help know, I've been trying to build R-patched on a dual Opteron box running Scyld Beowulf, using the PGI 6.1 compilers. The build went fine, but I couldn't get it to pass make check-all. Jennifer Lai, who reported success with

I am working on a SLES 10 cluster with R available on it. To better use my resources, I want to use Rmpi, but I am having a difficult time installing it. I have set the $R_LIBS variable correctly. The MPI libraries are available through the PGI compiler, but this R instance was compiled with GCC. The Rmpi package can be compiled and installed with %R CMD INSTALL Rmpi_0.5-5.tar.gz

Hi all, I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. On my example I got llc 3.2 to fail on following assertion: llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU

I am trying to compile R-devel (R-devel_2006-05-17.tar.gz) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) using the Portland Group compiler 6.0. (I have not yet successful compiled R on this configuration, so I don't know if this is a new problem.) I get an error pgcc -L/usr/local/pgi/linux86-64/6.0/libso -L/usr/lib64 -o dftables dftables.o ../dftables chartables.h

Hi, I followed this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028942.html, to compile ATLAS with gcc and g77 on AMD Opteron. I then followed the instructions on this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028966.html, to convert static libraries to dynamic libraries. However, when I tried to configure R-devel, I got the following error

I am trying to compile R-2.3.0 (both first release and patched 2006-05-10) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) using the Portland Group compiler version 6.1 and the notes from Jennifer Lai on p33 of "R Installation and Administration" version 2.3.0 (2006-04-24). I have not used this compiler before, so it is possible things are messed up more than usual, even

----- Original Message ----- > From: "Alex Bradbury" <asb at asbradbury.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>, "flang-dev" <flang-dev at googlegroups.com>, "Rob Neely" <neely4 at llnl.gov>, > "douglas miles (PGI)" <douglas.miles at

Hi everyone, I have some very good news for everyone interested a production-quality Fortran frontend for LLVM: The U.S. Department of Energy’s National Nuclear Security Administration and its three national labs have reached an agreement with NVIDIA's PGI division to adapt and open-source PGI's Fortran frontend, and associated Fortran runtime library, for contribution to the LLVM

Chad, et al, In addition to Doug’s excellent technical update, I’ll note that we are starting to have some discussions on the DOE side with PGI about establishing a more formal review team made up of some key LLVM stakeholders to help smooth the way for a broader public rollout of the Flang code base and eventual integration. We’ll probably rely on Hal and others here to help us figure out who

A bit off topic, but having trouble again with the 64-bit libs when trying to compile this short fortran code to build a shared object. Can anyone offer an explaination of what is meant by the relocation bit, and how to fix it? I've tried the -fPIC, but apparently I either didn't have it in the right place or it does not work. Be glad to take this offline if somone could help me.

> On May 26, 2016, at 1:57 PM, Neely, Rob via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Chad, et al, > > In addition to Doug’s excellent technical update, I’ll note that we are > starting to have some discussions on the DOE side with PGI about > establishing a more formal review team made up of some key LLVM > stakeholders to help smooth the way for a broader

Hi Chad - We have a functional Fortran compiler, with the PGI front-end bridged directly to LLVM, all of our Fortran runtime libraries integrated, and the Clang driver adapted for use with the Fortran compiler. We're working with a few users at DOE who are trying to compile big applications with a binary version of the compiler. Work is ongoing to migrate the source code into an LLVM-style

No closed doors intended here. Just a recognition that for something like an initial review to be useful, we probably have to be a bit careful in how many people we can reasonably involve before it could get unwieldy, and trying to be respectful of people’s time if we can nail down 90% of issues with a smaller group before going broader. I think we’d be fine with opening up the WebEx presentations

This process is certainly only open to a select group, so pragmatically it's closed. I can understand that it will certainly not be an easy process once it's public due to the amount of code and complexity. Maybe someone can comment on a specific issue - When we ported our Fortran front-end to target llvm, we found that Fortran ENTRY doesn't map very well to llvm ir. Can anyone who

Hi Chad, I can tell you that progress is being made on PGI's side; I'll let Doug/Rob provide more detailed updates. -Hal ----- Original Message ----- > From: "Chad Rosier" <mcrosier at codeaurora.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "flang-dev" <flang-dev at googlegroups.com>, "douglas miles (PGI)"

Hi Hal, I haven't been following this closely, but has there been any updates recently. Regards, Chad -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev Sent: Sunday, November 15, 2015 12:46 AM To: Hal Finkel <hfinkel at anl.gov> Cc: LLVM Dev <llvm-dev at lists.llvm.org>; flang-dev <flang-dev at