similar to: F18 import error?

Hello, This is regarding recent/ongoing discussions about F18 being merged in LLVM. I was going through these threads, and I found few important points which were possibly left unanswered (or I might have missed few threads). URL: http://lists.llvm.org/pipermail/flang-dev/2019-December/000120.html Point: Is (3) AST -> FIR -> MLIR LLVM-IR -> LLVM-IR) in a shape where we can

Hi llvm-dev We believe we have completed enough of the agreed pre-upstreaming changes to start talking about merging F18 into LLVM. The live status is tracked at [1]. There are a few details that we have not managed to hammer out and we propose to tackle inside the LLVM monorepo. I have put a summary of these at the bottom of this mail. Does anyone have any objections to flang being merged into

Hi all, On a F18, I installed livecd-tools-18.15-1 I downloaded CenOS6.x minimal .iso and with livecd-iso-to-disk the resulting USB is never bootable: the computer doesnt boot on it. Tested on many computers. The fact is I succeded to install CentOS on a Netbook (no CD/DVD tray), but I dont remember how I invoked livecd-iso-to-disk. I tried with many combinations (/dev/sdc is the USB

On Mon, Feb 25, 2019 at 2:45 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > And then there is also the argument for reusing Clang tooling, > which David Greene keeps making, though that idea does not seem to > get a lot of interest. > > > I disagree. There's been a lot of interest in modeling Flang's tooling > after Clang's

Hi Mehdi, I can't replicate those failures at my end, could you let me know what OS, compiler and CMake flags you're using so I can try and reproduce? Thanks! David Truby ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> Sent: 07 April 2020 06:44 To: Richard Barton

Hi all F18 merging has finished so commit access should be back to normal. Thanks Rich > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Richard > Barton via llvm-dev > Sent: 9 April, 2020 16:08 > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] F18 upstreaming Now! > > Hi all > > We are about to merge F18

Attached is the log. I'm building with: clang version 10.0.0 (https://github.com/llvm/llvm-project/ 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) Target: x86_64-unknown-linux-gnu Thread model: posix On some Ubuntu-like distribution. I also ran with ASAN once and it found a bunch of leaks in bin/tco. Best, -- Mehdi On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at

We've gone back to using an older machine that used to run libvirt just fine. Updated to F18, libvirt-1.1.0-1.fc18.x86_64. VirtualBox works ok. Now I can't start any image. For one machine i get: .............. File "/usr/lib64/python2.7/site-packages/libvirt.py", line 698, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)

On 4/10/19, 12:15 PM, "llvm-dev on behalf of Chris Lattner via llvm-dev" wrote: > The foundation recommends considering a new name for the project (e.g. flang or simply fortran) > to be more accessible and obvious for new contributors - in addition to being the repository name, > it will also be the base stem for mailing lists and other project related material. The f18

On 4/30/19 9:33 AM, David Greene via llvm-dev wrote: > "fortran" seems far too generic to me. What distinguishes it from a > different Fortran compiler? > > What about "flange" (Fortran language environment)? It's distinct from > the already-in-use-by-two-projects "flang" yet fits in with the existing > "clang" naming scheme. Plus it

Following up on my earlier email. If there is a commitment to checking in f18 already, feel free to disregard it. I went and took a little bit closer look at the sources and want to share some of the findings in case if anyone is interested. Disclosure: I contribute to Fort <http://fort-compiler.org/> (fort-compiler.org), which is the fork of the front-end David Greene mentioned. From

I''m using puppet-0.24.8-4.el5 on CentOS 5.4. My problem is yumrepo isn''t writing the "name=" field to the repository files which causes yum to complain with the error: Repository ''local-CentOS-5.4-x86_64'' is missing name in configuration, using id I get this behavior on all of my yumrepo definitions. One of them looks like this: yumrepo {

Hi, everyone, As you may know, NVIDIA has developed an open-source Fortran frontend for LLVM (http://flang-compiler.org), which consists of the flang frontend itself along with the corresponding Fortran runtime library. The existing frontend's code is mostly written in C, and while a production-quality implementation, does not follow modern software-engineering practices. Our long-standing

I run a local repo for our company's packages. Since yesterday we have problems with creating the repo files. When i run "createrepo --update -s sha rpmdir" i get the folowing error: File "/usr/share/createrepo/genpkgmetadata.py", line 249, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 223, in main mdgen.doPkgMetadata()

On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > >   > > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code > that

Run with LIBGUESTFS_ATTACH_METHOD=appliance Fails with: inspect_os: mount_ro: /dev/sda on / (options: 'ro'): mount: /dev/sda is already mounted or /sysroot busy at /usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm line 194. virt-inspector works as expected libguestfs-test-tool.log: http://pastebin.ca/2317900 virt-v2v.log: http://iaindb.pastebin.ca/2317938 Any

Hi list, I'm fiddling with CentOS 5.5 and kickstarted installations via cobbler. In my environment I need to install using the HTTP protocol over a proxy. Does anyone know why the URL command doesn't support the --proxy method? I get an Anaconda error message stating that this method is not supported. Even though i found out about that method in documentation. Relevant section in my

Am Sa., 2. März 2019 um 11:15 Uhr schrieb Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>: > I’d be really opposed to flang reusing the Clang ASTs themselves. C++ is already a complicated language and mixing all of Fortran's concerns (including a completely different object model) will make both of them *worse* than having them stand alone IMO. Could there be a common base