similar to: [LLVMdev] VS build is broken again

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

> Is it reasonable to ask Yes, it's reasonable. Moreover, I'd be content with a build system that doesn't use MSVS IDE at all. If the build system could be parameterized to use microsoft cl compiler (cygwin gcc is useless for my purposes), e.g. something like in Boost project, I'd be more than happy to never care about VS project files. Yet, I want to limit my involvement

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

I've come over an open source script which should be able to convert unix (gnu?) like makefiles to nmake. However, It possible needs some changes to work with the llvm makefile framework. Until then, I strongly suggest a repository for the msvc project files until we'll come with a lasting solution. It is natural that we, msvc guys, should keep these files in shape. Henrik.

> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for something Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so

2013/3/27 Anton Korobeynikov <asl at math.spbu.ru>: > Hi Eric, > >> From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs > No. They are using Windows Platform ABI for almost everything (e.g. > calling API, C runtime, etc.). At least mingw does. The differences > are exactly in unspecified area (e.g. passing / returning structs by >

Hi Anton, >From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs especially as we're not targeting the MSVC abi, it's just the windows abi? -eric On Wed, Mar 27, 2013 at 1:32 PM, Anton Korobeynikov <asl at math.spbu.ru>wrote: > Hi Timur, > > I myself find the name "Win32" pretty confusing and easy to misuse > (especially

> Sounds fine to me. I just wanted some convenient and consistent naming. > I think it conflicts a bit with the triples (-win32 currently means > msvc I think), Right. But this is again a historical (and LLVM-specific) artifact, because I doubt anyone uses such triplet outside to mean msvc compatibility. > but that'll probably be ok ultimately - internal function names are easy to

> A more specific question is - if I fix some Clang i686-pc-win32 > compatibility issue with MSVC for some language feature (e.g. > returning a struct), > should I make sure Clang i686-pc-mingw32 behavior is not changed by my > patches (a) > or should I make sure that Clang i686-pc-mingw32 generates > MSVC-compatible ABI for the same feature (b) > ? You need to make sure

On Fri, Oct 2, 2020 at 1:48 AM George Rimar <grimar at accesssoftek.com> wrote: > Thanks, David! > > > Few minor additions to the topic: > > > > I'm not sure which MSVC version on godbolt would be "MSVC 2017" that > the LLVM docs refer to > > > I've found that the minimal available version of MSVC on > godbolt is "WINE MSVC 2015:

Erik de Castro Lopo wrote: >> vsnprintf (MSVC, MinGW): >> >> buf_size = 8; ret = -1; buffer = "01234567ijklmnopqrstuvwxyz" >> buf_size = 9; ret = -1; buffer = "012345678jklmnopqrstuvwxyz" >> buf_size = 10; ret = 10; buffer = "0123456789klmnopqrstuvwxyz" >> buf_size = 11; ret

What if it's already broken? 2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> A more specific question is - if I fix some Clang i686-pc-win32 >> compatibility issue with MSVC for some language feature (e.g. >> returning a struct), >> should I make sure Clang i686-pc-mingw32 behavior is not changed by my >> patches (a) >> or should I make sure

Yeah, not sure either. The discussion about minimum compatibility usually comes down to what version is available on long-term OS releases. On Fri, Oct 2, 2020 at 12:38 PM George Rimar <grimar at accesssoftek.com> wrote: > > Is the code currently broken? > > > I don't know. Perhaps the code is fine, I did not try to compile LLVM > with all that compilers > >

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know so very little about Windows. However, if you compile

Hi Timur, I myself find the name "Win32" pretty confusing and easy to misuse (especially for someone who assumes that windows == msvc). After all mingw and cygwin is also win32. Maybe we should rename it into isTargetMSVC or something like this? On Wed, Mar 27, 2013 at 6:26 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Anton, > > What do you think? > >

Ralph Giles wrote: >> With current settings, MSVS links debug version of flac.exe (and other >> .exe and .dll files) with the release version of libogg_static.lib. >> MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use >> of other libs; use /NODEFAULTLIB:library" > > Sounds like a bug. Debug targets should link to debug builds

Dmitri Makarov <nebraskin at yahoo.com> writes: >> Is it reasonable to ask > > Yes, it's reasonable. Since this is open source we depend on contributions from the community, etc... You know how the song goes. Seriously, I'll like to see a healthy MSVS build as much as you, but someone must do the work. > Moreover, I'd be content with a build system that

On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Sounds fine to me. I just wanted some convenient and consistent naming. >> I think it conflicts a bit with the triples (-win32 currently means >> msvc I think), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to

Thanks for writing, Nate! Yikes, I totally missed those MSVS docs--it shows just how large and comprehensive LLVM has become! Thanks for helping clarify MSVS support! On Apr 1, 2011, at 2:03 PM, nate fries wrote: > Hi Andy. > This should be no problem, as long as you don't use MSVC's headers inside your scripted code (you should be able to use MinGW's to accomplish the

lvqcl wrote: > Ralph Giles wrote: > > >> With current settings, MSVS links debug version of flac.exe (and other > >> .exe and .dll files) with the release version of libogg_static.lib. > >> MSVS issues a "warning LNK4098: defaultlib 'libcmt.lib' conflicts with use > >> of other libs; use /NODEFAULTLIB:library" > > > > Sounds