similar to: [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

I'm not sure if they are doing an x86 to IA64 cross compile, but in any event I'm going to guess they may need an ancient version to avoid any C++11 dependencies. In terms of IA64 compilers you have afaik 3 choices HP compiler, Open64 and Intel? (Does gcc still support it and how up-to-date or EOL is the Intel compiler IA64 support?) I really hope nobody decides not to move to a more

Hello all, Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an

As part of our port of OpenVMS to x86-64, we are using LLVM with our own frontends on OpenVMS Itanium. We are writing a converter between our old backend's IR and the LLVM IR. We can cross-compile (hosted on OpenVMS Itanium) and link/execute on x86-64 CentOS. At present, we pass over 88% of our C test suite. Porting starts with being able to compile the code. Since we are stuck with a

Yes. We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an older EDG/Intel C++03 compiler to create legacy cross-compilers to our OpenVMS x86 box (well, VirtualBox). We do have a few tweaks to the relocations to access static data always through the GOT (including CodeGen's static data). Our linker sees references to code (which might be in 64-bit space) and creates trampolines

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF > Bastien via llvm-dev > Sent: Thursday, June 13, 2019 12:25 PM > To: John Reagan > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular > arithmetic, use `unsigned` only for bitmask and when you, intend to

Hello, I'd like to introduce myself, my company, and our upcoming use of LLVM. My name is John Reagan. I've been working on compilers and assemblers since 1983 (yes, 31 years). Most of that time was spent on compilers for VAX/VMS (later renamed to OpenVMS), then OpenVMS on Alpha, and OpenVMS on Itanium. I've also worked with the HP NonStop platform and was directly involved

On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> wrote: vector.size() returns a size_t, which on 64-bit platforms can represent types values larger than those that can fit into an int64_t. So to turn your argument around, since it's theoretically possible to have a vector with more items than an int64_t can represent, isn't it already worth it to use

On Wed, May 18, 2016 at 01:10:50PM +0000, Daniel Sanders via llvm-dev wrote: > It's my understanding that llvm-mc is intended to be a testing tool > for LLVM developers rather than an assembler for end users. Users > should be assembling with clang. Not all LLVM users are clang users. For example, we're using LLVM to build OpenVMS cross-compilers to x86 for our porting effort.

Keeping the documentation with large warnings is sufficient. It would at least let somebody then grab an older version's makefiles if they are so inclined/interested. I have no problem with you yanking the files, just the fact that older versions did have configure/makefiles. I only spoke up when I saw the suggestion for removing the online documentation. John -----Original Message-----

On 11/9/15 5:49 PM, John Reagan wrote: > That would be fine with me. I just don't want some new visitor to > come along and see "CMake only" and get discouraged and leave. Well, it is going to be "CMake only". Anyone who depends on autotools is going to be stuck on whatever the last revision is that we shipped with it. And I really don't see it being feasible

> On Nov 9, 2015, at 3:21 PM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 11/9/15 4:02 PM, John Reagan via llvm-dev wrote: >> Keeping the documentation with large warnings is sufficient. It >> would at least let somebody then grab an older version's makefiles if >> they are so inclined/interested. I have no problem

When I worked on the HPE NonStop compilers for x86 (we used Open64, not LLVM), we adjusted our -O1 to make sure the source display didn't "bounce around" based on feedback from users. We disabled any optimization that would move things across statement boundaries. We also disabled/de-tuned dead store since our DWARF location list support was pretty basic and with the removed store,

Meant to send this yesterday, but I want to remind everyone that we’re going to be raising the CMake minimum version to 3.4.3 next week. If you maintain bots please ensure that your bots are updated by end of day 5/29 so that we can move on 5/30 (next Monday). I have already heard from most bot owners either saying they had made the change, or scheduled to make it. If you have any questions or

I am ready, regarding to, http://bb.pgr.jp/ On Wed, May 25, 2016 at 5:54 AM Chris Bieneman <beanz at apple.com> wrote: > Meant to send this yesterday, but I want to remind everyone that we’re > going to be raising the CMake minimum version to 3.4.3 next week. > > If you maintain bots please ensure that your bots are updated by end of > day 5/29 so that we can move on 5/30

All the MIPS buildbots are ready too. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of NAKAMURA Takumi via llvm-dev Sent: 25 May 2016 23:03 To: Chris Bieneman; llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org; lldb-dev at lists.llvm.org Subject: Re: [llvm-dev] [Attn: Bot Owners!] Raising CMake minimum version to 3.4.3 I am ready, regarding to, http://bb.pgr.jp/ On

> > Replicating ExternalProject would be a lot of work... > One approach commonly used with CMake modules that change frequently upstream is for the project to keep a local copy and have a check in place to use CMake's version if new enough. For instance, in llvm's source tree: cmake/modules/ExternalProject.cmake: if(CMAKE_VERSION VERSION_LESS "3.5.1")

> On 27 Apr 2016, at 14:47, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > On 27 April 2016 at 13:42, Bruce Hoult <bruce at hoult.org> wrote: >> cmake is a big dependency, but it doesn't seem to have many dependencies >> itself. They say it's just a C++ compiler and a make (not necessarily gnu). >> Probably there are one or two more

Chris, We have upgrade our bots (both internal and external) to CMake 3.5.2. So we are good to go. -Mike On Tue, May 3, 2016 at 12:29 PM, Chris Bieneman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato, > > This approach sounds great to me. > > Chris M let me know separately that GreenDragon is on CMake 3.5. > > I belive Galina and Takumi maintain the

> To be clear, I'm not against moving the version up, I just want to > make sure that people understand that this is not *just* a version > upgrade, but a development philosophy move for all Linux developers > and production environments (of which we have plenty). This move was > proposed before and was rejected for the reasons I pointed out: > maintenance. Yes. It is a move