similar to: [LLVMdev] alternate clang driver

On 02/24/2014 04:42 PM, Eric Christopher wrote: > On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >> I need to leave soon and will take a look in the morning. >> >> I did look at the autoconf input files configure.ac >> >> There is a disable-zlib but not a disable-valgrind, even though it seems >> like there used to be.

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

I need to leave soon and will take a look in the morning. I did look at the autoconf input files configure.ac There is a disable-zlib but not a disable-valgrind, even though it seems like there used to be. You can find scripts on the internet when you google of people adding disable-valgrind to configure. I can probably implement disable-valgrind in configure.ac. Reed On 02/24/2014 04:33

On 02/24/2014 04:19 PM, Eric Christopher wrote: > On Mon, Feb 24, 2014 at 4:14 PM, reed kotler <rkotler at mips.com> wrote: >> I'm trying to build a native hosted mips compiler on ubuntu x86. >> >> When I run configure with clang/llvm as the compiler, configure thinks that >> zlib is present and that valgrind is. >> >> But later on the make it

On 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

On 02/25/2014 09:30 AM, Richard Sandiford wrote: > reed kotler <rkotler at mips.com> writes: >> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >>>> I need to leave soon and will take a look in the morning. >>>> >>>> I did look at the autoconf input files

On 08/16/2013 02:13 PM, Eli Friedman wrote: > On Fri, Aug 16, 2013 at 2:01 PM, reed kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > the good news is that (thanks to Simon) the clang driver is > working so well for Mips now that we are more or less switching > away from using llc during development for all our various >

Geting a seg fault. Have not investigted the cause. rkotler at mipsswbrd002:~/richard$ tar vfxz ~/Downloads/ellcc-mips-linux-2014-Mar-24-07-32-26.tgz rkotler at mipsswbrd002:~/richard/ellcc/bin$ gdb ./ecc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are

On 08/16/2013 02:23 PM, David Chisnall wrote: > On 16 Aug 2013, at 22:01, reed kotler <rkotler at mips.com> wrote: > >> we used to be able to just make in the lib/target/Mips and then in llc and it was really fast. >> >> part of it is probably that we have all this debug information that we don't need because none of use are working on clang itself (well, almost

the good news is that (thanks to Simon) the clang driver is working so well for Mips now that we are more or less switching away from using llc during development for all our various host/target configurations. the bad news is that we have make clang all the time and it is really slow to do that. we used to be able to just make in the lib/target/Mips and then in llc and it was really fast.

In case anyone is interested.... We don't need to compile llvm/clang using gcc anymore for the building of mips hosted llvm compilers. We build a linux mips hosted compiler starting with llvm/clang on x86 linux using the normal configure scripts and then can use that resulting compiler to build further llvm/clang native compilers on the mips linux host. The cross compiler and native

On 08/16/2013 01:42 PM, Renato Golin wrote: > On 16 August 2013 20:02, reed kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > -std=gnu89 is not valid for c++ > > > I think the point here is that this is the default std for GCC but not > Clang, so you have to force clang to behave like GCC. For C++, you'll > have to force

On Fri, Aug 16, 2013 at 2:01 PM, reed kotler <rkotler at mips.com> wrote: > the good news is that (thanks to Simon) the clang driver is working so > well for Mips now that we are more or less switching away from using llc > during development for all our various host/target configurations. > > the bad news is that we have make clang all the time and it is really slow > to

On 16 August 2013 20:02, reed kotler <rkotler at mips.com> wrote: > -std=gnu89 is not valid for c++ > I think the point here is that this is the default std for GCC but not Clang, so you have to force clang to behave like GCC. For C++, you'll have to force whatever default GCC has for it's C++ standard. Though, GCC 4.8 is getting very close to Clang's behaviour, so

I'm trying to build a native hosted mips compiler on ubuntu x86. When I run configure with clang/llvm as the compiler, configure thinks that zlib is present and that valgrind is. But later on the make it cannot find zlib.h. If I tell it to not do compression, then it does not look for zlib.h but dies looking for valgrind, even if I tell it to disable-valgrind. If I configure using

Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be

On 16 Aug 2013, at 22:01, reed kotler <rkotler at mips.com> wrote: > we used to be able to just make in the lib/target/Mips and then in llc and it was really fast. > > part of it is probably that we have all this debug information that we don't need because none of use are working on clang itself (well, almost never). > > ideas? I build a dynamically-linked version of

My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done.

We are considering running clang format on the whole Mips target. Is there any rule against this? Is there any good argument against doing this even if there is no rule against it? TIA. Reed

Are you debugging the driver process or the -cc1 process? To get the -cc1 process, unfortunately you have to go through the dance of passing -### to get the -cc1 line and then run that in gdb (or write one manually). Alternatively in gdb you can say "set follow-fork child" (or something, check the docs) to automatically follow into the -cc1 child. On Tue, May 21, 2013 at 8:00 AM,