similar to: [RFC] Deprecating autoconf: Let's do it!

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

Hi LLVMDev, Since my last update we’ve landed patches for these issues: * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config * Bug 23746 - test-suite lacks CMake support * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig On my last thread Jonathan Roelofs pointed out that there is a workaround for Bug 21568 (Cannot add rpath), so I’m making it

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

As one of the OS' without current CMake support, I'm closely watching this discussion. We currently have LLVM 3.4.2 hosted on OpenVMS Itanium (as a host only, x86 target) using configure/make with little hassle. We plan to port CMake to OpenVMS, but that has been trickier than you'd think (others have tried, I haven't found anybody who has done it). Looks like I'll want to

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

Hi LLVMDev, There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947. The following issues have been marked as fixed since the last

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

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

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,

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.

Hi LLVMDev, The following issues have been fixed since the last update I sent out. Completed: * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions * Bug 21561 - Update release scripts to use CMake These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs

Hi Brenden, Thanks for the heads up. I don’t expect that to be a blocker for deprecating autoconf because autoconf doesn’t have an equivalent of LLVMExports.cmake. That said it is a real issue and I’ll track it with the other issues on this list, and I’ve added it as a dependency on the meta bug (PR15732) to make it easier to keep track of. Thanks, -Chris > On Jul 29, 2015, at 4:48 PM,

Hi Chris, Looking forward to continued support for CMake! Along that note, I wanted to add one bug to your list of things to track, which to me seems up your alley but maybe was filed in the wrong bucket (or is actually someone else's problem). Bug 24154 - CMake shared files are broken in llvm-3.7-dev Cheers, Brenden On Wed, Jul 29, 2015 at 1:20 PM Chris Bieneman <beanz at

On Fri, Nov 06, 2015 at 04:17:04PM -0800, Hans Wennborg via llvm-dev wrote: > On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi LLVMDev, > > > > Since my last update we???ve landed patches for these issues: > > * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config > > * Bug 23746 - test-suite

We use .note descriptors with ELF on OpenVMS.  We have self-describing entries with tags and lengths.  The compiler encodes stuff for the linker such as compiler version, compilation date-time, module name, final severity of the compilation, etc.  The linker itself then adds/modifies the .note entries to insert linker version, link date/time, etc.  We also use .notes to record floating point