similar to: [LLVMdev] Default targets and MS Visual C++

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you

When using cmake to configure the LLVM build for building with MS Visual C++ only the X86 target is built by default, whilst for any other compilation system all targets are built by default. I was just wondering whether there is a current reason for this difference of the default targets just for MS Visual C++, or whether all targets should now be built for all targets by default? Keith

On Sat, Apr 7, 2012 at 11:58 PM, Alan Garny <agarny at hellix.com> wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > > Michael Spencer <bigcheesegs at gmail.com> writes: > > > The problem is that MSVC++ requires sprinkling > > > __declspec(dllexport/dllimport) all over the code, and we really don't > > > want to deal with maintaining

Chris Lattner <clattner at apple.com> writes: > This thread is odd to me. It seems that the gist of your guys' > argument is that you don't know if we will ever get full support, > therefore we don't welcome progress towards that (very useful) > goal/feature. > > If the specific proposal doesn't make make sense from a design > standpoint, that's one

On Jul 31, 2013, at 3:13 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Full disclosure: I'm the guy who filled the PR requesting the feature > the OP's is working on and, when someone tried to close it as WONTFIX, I > strongly opposed. Furthermore, MSVC++ is my Windows compiler and my > projects suffer from unwelcome complexity for working around the lack of > this

IMHO, the CMake-based build system is almost complete enough to replace current MSVC++ project files (modulo some community review and bug-fixing). Is this enough for adding it to the LLVM repo? >From the point of view of a MSVC++ user, the new build system is trivial to maintain: you can add a new library or tool executable in less time that it takes to open the project file on MSVC++, it

Óscar Fuentes <ofv at wanadoo.es> writes: >> It appears the Windows build has regressed over the past week. >> >> The build fails quite early (during the "Performing TableGenStep" >> phase). >> >> Any help/pointers would be appreciated. > > It breaks for me because the usage of INT64_C, which was introduced on > r57663 and 57668. >

On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: Oscar, just FYI, your wording is very strong, and that is often not the most productive way to make your point. That said, to address some of the things you've raised in a couple of threads: >> If you think these are irrelevant points then you need to state why >> and should back it up with less

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > Óscar Fuentes wrote: >> All the headers in include/llvm? Or just those local to each library? >> > > All the headers. It's a pain to manually update the project files but it > will be a bigger pain trying to use them without the include files.. > included. There are almost 300 headers under include/llvm.

I have updated "DataTypes.h.in", could you do a svn update and see if it works ? -Argiris Óscar Fuentes wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > > >>> It appears the Windows build has regressed over the past week. >>> >>> The build fails quite early (during the "Performing TableGenStep" >>> phase).

Russell Wallace <russell.wallace at gmail.com> writes: > C:\llvm\bin>llc -version > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6svn > DEBUG build. > Built Jan 31 2010(20:46:01). > > Registered Targets: > x86 - 32-bit X86: Pentium-Pro and above > x86-64 - 64-bit X86: EM64T and AMD64 > > I did specify the release build

On Fri, Apr 6, 2012 at 6:15 PM, Alan Garny <agarny at hellix.com> wrote: > Hi, > > From what I have seen on this mailing list and elsewhere, it would seem that > it isn’t possible to build LLVM as a shared library using Visual C++. Still, > I would imagine that quite a few people are or would be interested in it, > so… is there any plan to support this any time soon? This,

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: > On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) >> and Anton kindly explained that LLVM is doing the right thing as per the >> ABI (the GCC ABI, I'll add). >> >>  1. Is there a LLVM way of

On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) > and Anton kindly explained that LLVM is doing the right thing as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what

On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> Also, now msvc support multiple target. So it's better to set it as >> ${LLVM_ALL_TARGETS} >> It's can working, why not set it to:. > > I think most LLVM users on Windows are interested on X86 only. This > saves a lot of time on the build process and creates smaller >

Hi Óscar, Thank you for your reply. It looks like the limitations are the platform's API and ABI (included the size of variable). So, if there are two platforms that have the same API, ABI but different ISAs, the bitcode can be shared. Can I say that? Thanks, Kenia Kuo 2012/9/25 Óscar Fuentes <ofv at wanadoo.es> > Kenia Kuo <kenkillerkuo at gmail.com> writes: > >

C:\llvm\bin>llc -version Low Level Virtual Machine (http://llvm.org/): llvm version 2.6svn DEBUG build. Built Jan 31 2010(20:46:01). Registered Targets: x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 I did specify the release build with cmake; the lack of crashing on exit of programs compiled therewith confirms that :-) As far as I can see, the

Eli Friedman <eli.friedman at gmail.com> writes: > On Sun, Aug 9, 2009 at 10:03 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> I think most LLVM users on Windows are interested on X86 only. This >> saves a lot of time on the build process and creates smaller >> executables. Anyways, it they want all targets, it is simply a matter of >> passing

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx

On Tue, Sep 16, 2014 at 7:47 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > IIUC zlib availability is tested and the library used if present. Do you > mean that LLVM does not use zlib on Windows when the library is present? Sure, but if there aren't instructions for how to do it easily, then it's effectively unsupported. There isn't really a canonical way to