similar to: [LLVMdev] Lost target in Triple

Hello > I add solaris and pic16. > And add support for mingw. Mingw part is not ok. The proper rules should be: i[[3456789]]86-*-mingw32* => mingw32 x86_64-*-mingw* => mingw64 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Is it possible to merger mingw32 and mingw64 with mingw, because we can distinguish them with arch(i386,amd64) 2009/8/15, Anton Korobeynikov <anton at korobeynikov.info>: > Hello > >> I add solaris and pic16. >> And add support for mingw. > Mingw part is not ok. The proper rules should be: > > i[[3456789]]86-*-mingw32* => mingw32 > x86_64-*-mingw* =>

Hi, I intend to participate in Google's Summer of Code this year, so I'd like to bounce another idea around to see what you guys think. (I posted a similar message to cfe-dev just now.) Be warned: this will shock you. It may even horrify you. 1. Implement a 16-bit x86 backend. (*Chris recoils in horror*) Yeah, I know 16-bit x86 is dead, but I find it interesting for historical purposes

>> Mingw part is not ok. The proper rules should be: >> >> i[[3456789]]86-*-mingw32* => mingw32 >> x86_64-*-mingw* => mingw64 I add support for pic16, // PIC16: pic16 Solaris, For the consistency and simplicity, and merge MinGW32 and MinGW64 to MinGW. And some change in Triple.cpp for the clang project. -- Yours sincerely, Yonggang Luo

Notice!! sorry for that, the patch is incorrect, i attached the new one. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- A non-text attachment was scrubbed... Name: triple.patch Type: application/octet-stream Size: 3745 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090815/9429c396/attachment.obj>

Is there anyone get the time to apply this patch? 2009/10/2, Douglas Gregor <dgregor at apple.com>: > > On Oct 1, 2009, at 6:36 AM, 罗勇刚(Yonggang Luo) wrote: > >> At the first glance, it's coming with that c-index-test is just >> only containing c files (without cpp(cxx,c++) files). >> >> So cmake recognize it as pure C project, >> and so it's

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 <delta> ) declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> ) declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8

-- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091001/be44334c/attachment.html>

> > I've committed my suggested fix. There's no point in setting the > LINKER_LANGUAGE property of every LLVM library, because CMake figures out > the right language based on the file extensions of the source files. Yes, CMake figures out the *right language* based on the file extensions of the source files. But, llvm is based on *C++* for example, if you create a application

Looks like you forgot to attach the patch. Ciao, Duncan.

Hi all, When I try to build llvm on windows/mingw32, I get the following error: In file included from c:/work/mingw/src/llvm/lib/System/Signals.cpp:33: c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc: In function 'LONG LLVMUnhandledExceptionFilter(_EXCEPTION_POINTERS*)': c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc:275: error: exception handling disabled, use -fexceptions to

On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote: > On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: >> >> The required efforts equal to ones required to write new assembler. >> "Too weak to be usable" means "it's not possible to represent many >> important constructs with masm/nasm/fasm". > > Wow. It's perhaps too much of a

How are bitfields handled in StructLayout? In LLVM 2.5 the struct is unambiguously size by: StructSize += TD.getTypePaddedSize(Ty); // Consume space for this data In LLVM 2.6 it's getTypeAllocSize, which does the same thing. Unfortunately, this is not correct for bitfields. For example, LLVM reports this struct: typedef struct test1 { short f0 : 10; char f1 : 5; long f2 : 1;

> Nope, llvm's .s output is only compatible with GAS and other at&t syntax > assemblers.  It turns out that MASM syntax is highly ambiguous and MASM is > not production quality for use by a compiler.  This is why visual studio > doesn't go through it.  Long term, we'd like LLVM to be able to write out .o > files directly, if you're interested in adding PECOFF

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

On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: > > The required efforts equal to ones required to write new assembler. > "Too weak to be usable" means "it's not possible to represent many > important constructs with masm/nasm/fasm". Wow. It's perhaps too much of a distraction, but I'm curious about the details of this. It's probably because

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

On Oct 5, 2009, at 3:17 PM, 罗勇刚(Yonggang Luo) wrote: > Is there anyone get the time to apply this patch? I've committed my suggested fix. There's no point in setting the LINKER_LANGUAGE property of every LLVM library, because CMake figures out the right language based on the file extensions of the source files. - Doug > 2009/10/2, Douglas Gregor <dgregor at apple.com>:

I truly get the bytecode file for each souce file,but can I use llvm-link to link them into a whole-program one automatically through some scripts? > > Message: 27 > Date: Tue, 15 Sep 2009 03:16:10 +0200 > From: ?scar Fuentes <ofv at wanadoo.es> > Subject: Re: [LLVMdev] Replace gcc with llvm-gcc??? > To: llvmdev at cs.uiuc.edu > Message-ID: <87vdjlnh2d.fsf 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