similar to: [LLVMdev] 64bit binaries in 32bit prerelease

Hi. I just stumbled across the fact that the following file http://llvm.org/pre-releases/3.4/rc2/clang+llvm-3.4-rc2-i586-opensuse13.1.tar.gz contains only 64bit binaries in bin/ . Is this intended? Anyway: Thanks for the excellent work so far! Sven

I still haven't finished but I don't think you have to wait. On Fri, Feb 27, 2015 at 7:46 AM, Renato Golin <renato.golin at linaro.org> wrote: > We got everything, haven't we? > > On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > > Final has been tagged, I think we're about to release it. > > > > On Fri, Feb 27,

On Thursday, January 15, 2015 06:55 AM, Nikola Smiljanic wrote: > Was there an rc3 that I missed? > It's not tagged if there was. I've tested and uploaded 3.5.1 final for x86_64-ubuntu-14.04. I think the rc2 build required a newer libstdc++ than exists on Ubuntu 14.04, but the final build should be good. Ben

On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > The problem is not in the functions that return multibyte strings (the > multibyte string is coming from argv) argv is implicitly the return from a UTF16->multibyte conversion (i.e. it's lossy). -Eli

On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > So what are you exactly saying? Somebody proposed using GetCommandLine > instead of using argv directly. And what about my other points about ::open > and ::stat? Because of the way Windows works, the only fully correct solution is to never touch the native charset, and keep everything in UTF-8/16

You're not the only one Hans, my VMs have started crashing my host OS :) Fedora and OpenSUSE look good, binaries uploaded. On Sat, Dec 13, 2014 at 12:06 PM, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Dec 11, 2014 at 5:26 PM, Tom Stellard <tom at stellard.net> wrote: > > Hi, > > > > 3.5.1-rc1 has been tagged, so it is time to begin testing. We

We got everything, haven't we? On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > Final has been tagged, I think we're about to release it. > > On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> > wrote: >> >> Are we waiting for an RC5? It seems like the release mirror on github has >> no

So what are you exactly saying? Somebody proposed using GetCommandLine instead of using argv directly. And what about my other points about ::open and ::stat? On Wed, Sep 7, 2011 at 8:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> > wrote: > > The problem is not in the functions that

What is the procedure now? Do we just wait for someone else to look at it and commit (I'm guessing that you don't have commit access)? cfe-commits is in the CC. On Tue, Oct 11, 2011 at 6:55 PM, Aaron Ballman <aaron at aaronballman.com>wrote: > Looks good to me! > > Thanks! > > ~Aaron > > On Tue, Oct 11, 2011 at 2:26 AM, Nikola Smiljanic <popizdeh at

Nikola Smiljanic <popizdeh at gmail.com> writes: > I'm not sure if this makes a difference but I ran this > > make -j 2 -k LLVMCC_OPTION=clang ENABLE_BUILT_CLANG=1 ENABLE_PARALLEL_REPORT=1 TEST=simple report > ../../report.txt 2>&1 That does indeed seem to get me further. Thanks! -Dave

Building phase 2 fails on i686 Fedora 22 CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686: CMakeError.log attached On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > The problem is we "guess" that the host architecture is i686, and fail > when we find out that we can't target it (__i686__

As was mentioned once before, the correct solution is to never use multibyte anywhere. Any Windows functions that currently return multibyte strings should be converted to their wide-string (unicode) equivalent, with the result converted to UTF-8. > From: Nikola Smiljanic <popizdeh at gmail.com> > > I think I got it this time. I realized that ::open and ::stat work just fine with

Final has been tagged, I think we're about to release it. On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> wrote: > Are we waiting for an RC5? It seems like the release mirror on github has > no recent activity. > > On Wed, Feb 25, 2015 at 3:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com > > wrote: > >> Quick update

I agree they are broken on all platforms. However, FileManager.cpp already contains an #if WIN32 conditional around the code calling LowercaseString, so you can use MultiByteToWideChar and CharLowerBuffW directly there, and not call the LowercaseString function. I don't think there are any other places where LowercaseString is called with non-ascii data, so you can punt on fixing it for now.

You can use _iswupper and _towlower instead of CharLowerBuffW. They don't require windows.h and work with /Za. On Sep 30, 2011, at 12:24 AM, Nikola Smiljanic wrote: > I tried to do the conversion to lowercase inside GetFullPath by adding an additional bool parameter to this function. It's not perfect but seems much better than repeating the whole UTF8 to UTF16 and UTF16 to UTF8

I spent some more time on this. My idea was to use functionality from llvm::sys::fs like file_status instead of stat struct, but as it turns out this is not really possible. file_status structure is not a replacement for stat, nor are there functions inside llvm::sys::fs that can replace calls to ::stat and ::open. The only solution I can see is to create wrappers around ::stat, ::open, etc. and

I think the assert you have for _stat64i32 is fine. It is a constant expression so should compile to nothing, and the chance of the definition changing is pretty much zero. LowercaseString appears to be used by ASM printers where the output is expected to be ASCII, and then some WIN32-conditioned code in FileManager.cpp. I hate to say it but you'll probably need to convert the UTF-8 paths to

Locale-specific is not what we want, but I don't believe Windows exposes an alternative API that does what we want. (Does CharLower give a different answer than tolower?) However, looking over the FileManager code a little more I'm not even sure using the path is the best solution, it seems it would be better to use inode like the unix code does. Windows doesn't support inode (the

CharLowerW does the right thing. But I still need Windows.h to use it :) On Mon, Oct 3, 2011 at 8:43 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > Locale-specific is not what we want, but I don't believe Windows exposes an > alternative API that does what we want. (Does CharLower give a different > answer than tolower?) > > However, looking over the FileManager code

No regressions this time. Fedora and OpenSUSE binaries uploaded. On Sat, Apr 26, 2014 at 12:47 PM, Tom Stellard <tom at stellard.net> wrote: > Dropping llvmdev and cc'ing testers directly, so this email > won't be held in moderation for having too many recipients. > > I like having tester discussions on list, so it would probably > be best to reply to the original