similar to: [LLVMdev] I know why msvc broken:(

2013/10/23 Reid Kleckner <rnk at google.com> > I don't think we should attempt to mangle symbols declared in assembly > source files. If you're writing assembly, you will need to handle ABI > Sorry for the unclear statements, I didn't means the assembler to mangle symbols declared in assembly source files, I means directly use assembly directive to choice which symbol

Going to be interesting layering issues if you do the latter. Then you have CodeGen depending upon DebugInfo instead of just a header in Support. -eric On Fri, Jun 28, 2013 at 11:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > For example, > ELF.h MachO.h and COFF.h > should moved into Object directory with new name. > and Dwarf.h should moved into DebugInfo

For example, ELF.h MachO.h and COFF.h should moved into Object directory with new name. and Dwarf.h should moved into DebugInfo directory. 2013/6/29 Eric Christopher <echristo at gmail.com>: > Where would you like to move them? > > -eric > > On Fri, Jun 28, 2013 at 10:38 AM, 罗勇刚(Yonggang Luo) > <luoyonggang at gmail.com> wrote: >> From my point of view, the

I know pc-lint is working fine on detecting some nasty coding fault. But is it illegal implement it in clang? And also there is so much other tools for code analyze:) 2010/3/26, yiqiuping1986 <yiqiuping1986 at 126.com>: > 呵呵，不急，还有一学期的时间。 > > > 2010-03-26 > > > > yiqiuping1986 > > > > 发件人： 罗勇刚(Yonggang Luo) > 发送时间： 2010-03-26 15:05:33 > 收件人：

I means visual studio c++ 2008, do you build clang+llvm with .sln files, and these files are generated by cmake? I do of that. And because vs c++ can't recognize path such a:/filepath/.. Properlyn it's recognized as a:/filepath So we need change /.. to /../ or /../. 2009/8/6, Daniel Dunbar <daniel at zuster.org>: > I don't understand this problem, I have built clang on

I found that access llvm-mc from clang driver is impossible, and I want to use llvm-mc to compile assembly files, how to do that? H:\CI\bld\compilers\musl\src\math\i386>clang -c -v --target=i686-pc-mingw sqrt.s clang version 3.4 (trunk) Target: i686-pc-mingw Thread model: posix Selected GCC installation: "gcc" -v -c -m32 -o sqrt.o -x assembler sqrt.s clang.exe: error: unable to

I don't think we should attempt to mangle symbols declared in assembly source files. If you're writing assembly, you will need to handle ABI portability, including the _ prefix on win32 x86. clang will run the C preprocessor for you if you use the .S file suffix (case matters). On Tue, Oct 22, 2013 at 7:08 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > For example, I

Its seems an bug in langref, is there anyone have an look or give an explain? 2010/5/5, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>: > declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) > declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) > declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32

I don't know if hg is a possible choice for llvm-project. Because we can using hgsubversion interactive with subversion. That's means we need only an svn server. and create an hg minor. And we can push to and pull from the subversion server. ---------- Forwarded message ---------- From: 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> Date: 2010/3/4 Subject: I can't find the

It is possible to statically link against libstdc++, yes. I don't quite know all the pieces to the recipe in order to get that to work. It would require changes to the release script in order to get those configuration changes all the way through the third phase build. I don't believe any other tarball release does this, so it would at least be an unconventional release. On Wed, Jun

So CentOS before 6.7 is not an option after all? Is that possible to use clang on CentOS 6.6 and before? On Wed, Jun 29, 2016 at 12:48 AM, Brian Cain <brian.cain at gmail.com> wrote: > Yes, I believe it was built against centos 6.7. I wanted to build it > against an older release but couldn't quite bootstrap it without newer > libstdc++. > > Sorry, it would be clearer

Where would you like to move them? -eric On Fri, Jun 28, 2013 at 10:38 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > From my point of view, the Support library should be more pure. And > should not contains > too much LLVM-related APIs and defines, > -- > 此致 > 礼 > 罗勇刚 > Yours > sincerely, > Yonggang Luo > >

Well, is that possible to include libstdc++4.7 into llvm? On Wed, Jun 29, 2016 at 2:26 AM, Brian Cain <brian.cain at gmail.com> wrote: > Sorry if I was unclear, I have no problems building clang against a newer > gcc for my own purpose. But it doesn't make sense to provide a release > binary for clang that's hosted on llvm.org that's ostensibly for >

I can confirm I get the same behavior, and that's a real bug. If you use --target=i686-pc-win32, you get COFF, and that should be a good workaround for now. There must be a conditional somewhere that isn't handling mingw correctly. On Sat, Oct 19, 2013 at 7:58 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > 2013/10/19 Rafael Espíndola <rafael.espindola at

>From my point of view, the Support library should be more pure. And should not contains too much LLVM-related APIs and defines, -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo

2013/10/19 Rafael Espíndola <rafael.espindola at gmail.com>: > On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: >> I found that access llvm-mc from clang driver is impossible, and I >> want to use llvm-mc to compile assembly files, how to do that? > > Try "clang -integrated-as -c test.s" Thank you very much, I use the

Sorry if I was unclear, I have no problems building clang against a newer gcc for my own purpose. But it doesn't make sense to provide a release binary for clang that's hosted on llvm.org that's ostensibly for "centos6" when it would really be bound to "centos6 plus the SCLO mirror which has the dependency for a newer libstdc++". The glibc 2.14 dependency is a

Ah, so clang only understands the spelling mingw32, not mingw. That'll give you COFF. :) On Mon, Oct 21, 2013 at 11:23 AM, Reid Kleckner <rnk at google.com> wrote: > I can confirm I get the same behavior, and that's a real bug. If you use > --target=i686-pc-win32, you get COFF, and that should be a good workaround > for now. There must be a conditional somewhere that

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

720beaedce6f19c81156fe20168f85989a8db53d CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index bb70f15..e327427 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -249,7 +249,7 @@ set(LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_HOST_TRIPLE}" CACHE STRING set(TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")