It's important to remember that Lattice Semiconductor is the official maintainer of the LM32 GCC code that gets fed back into the mainline tool. We need to be aware of problems with the compiler results in order to correct issues with the GCC code. If the MM community knows of issues and is not reporting them to us the GCC tools are never going to be corrected. IMO, GCC is the 800 pound gorilla of the C development tools within the FOSS realm. It's important for Lattice to make sure the GCC tool emits code that makes the LM32 do the right thing. I recommend that any bugs that are known to exist as a result of MM development be sent to [email protected]. It will benefit you by making the LM32 perform the code you've written, and it will benefit every other LM32 user as well.
> -----Original Message----- > From: [email protected] [mailto:devel- > [email protected]] On Behalf Of David Kuehling > Sent: Wednesday, February 08, 2012 3:12 PM > To: Milkymist developers' list > Subject: Re: [Milkymist-devel] Clang/LLVM > > >>>>> "Sébastien" == Sébastien Bourdeauducq <[email protected]> > writes: > > > On 02/08/2012 06:58 PM, JP Bonn wrote: > >>> Do you think we can start submitting it upstream? > >> > >> No. They will require someone to be committed to maintaining it. I > >> can't make that commitment at this point > > > Well, this is a lesser evil :) > > > gcc-lm32 has been completely broken for more than a year now due to > > various regressions introduced by other people. GCC's obscure > > spaghetti code not only makes bugs more difficult to fix, but also > > there can't be a month without a commit destroying your port, often in > > a way that wastes massive amounts of time to sort out. The situation > > seems better with LLVM and this is the main reason why I believe we > > should switch to it. > > Just one word of caution: I've been eying the milkymist-openwrt port, and > I'm quite sure that much Linux software is going to be better off with gcc > (especially g++) instead of llvm. If we do the switch now, incentitives to > fix > gcc bugs will be reduced, which may make the Linux userspace porting > efforts a bit more difficult in the future... > > I'm also thinking about a Debian port, once the MMU stuff etc. is done, > integrated with the kernel etc. (not this year anyways?), and I really don't > see how that would work without GCC. > > With you guys constantly bashing GCC, binutils, "autocrap" autotools, etc. I > cannot help but to cite an Emacs developer: > > it is often said that small is beautiful. now, anything can be > beautiful when it is small. the ugliest person you can think of was > probably a quite pretty baby. it doesn't take much effort to find a > beautiful 16-year-old girl, either. in fact, our modern notions of > beauty and elegance are _defined_ in terms of size and maturity, so > the chance of anything small and immature being beautiful is vastly > higher than anything big or mature. [..] > [1] > > Just my $0.02 > > cheers, > > David > > [1] http://www.emacswiki.org/emacs/ErikNaggum#toc5 > -- > GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg > Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
